Onk*_*nki 7 java polymorphism multithreading synchronization
synchronized不是方法签名的一部分.但是当我们覆盖一个方法时,它不仅仅是方法签名决定了被覆盖的方法是否会被编译.
例如,我们无法添加或扩大已检查的异常
为什么synchronized在多态性中没有作用.一个synchronized方法不应该不把覆盖synchronized.由于使用超类变量的人可能认为所有方法都是线程安全的.
但是,应该允许覆盖非同步方法,synchronized因为它添加了更多功能,但另一方面,除了时滞之外,用户不会遇到任何错误.
我正在寻找一个合乎逻辑的解释,可以说明"为什么设计如此".
如果不进行"同步",则不应覆盖"同步"方法.
错误.基类可能不是线程安全的,但子类可能有自己的同步,例如锁,无锁线程安全数据结构等.并非所有线程安全方法都是同步的,并非所有同步方法都是线程安全的.
同样可以朝另一个方向发展(但可能违反其他原则,视具体情况而定)
synchronized不是面向对象的东西,而是运行时/执行现象和实现细节.它所做的就是以相同的方式获取监视器synchronized(this){ }(或者如果是静态的话,在java.lang.Class对象上同步).作为一个实现细节,将它暴露给OOP考虑是没有意义的.
注意:这并不意味着编译时注释等@ThreadSafe没有意义.确实如此,因为它引用了方法的契约是线程安全的.synchronized不这样做.
你可以看到JDK-4294756的解释,一个方法可以覆盖另一个而不保留synchronized修饰符.此错误报告要求编译器在方法重写synchronized方法但未声明自身时显示警告synchronized,并将其关闭为"无法修复".关键原因如下:
使用synchronized修饰符以及通过显式"synchronized"语句进行的其他同步是实现由类表示的抽象的一部分,并且在子类中捕获的替代实现可以使用不同的同步策略以便实现等效的语义.例如,考虑这样一种情况,其中较大的非同步方法中的小临界区(受"同步"语句保护)替换了由同步方法修饰符完全保护的较小方法.
因此,缺少synchronized修饰符并不一定意味着该方法不是线程安全的.线程安全可以在方法内细化.
| 归档时间: |
|
| 查看次数: |
145 次 |
| 最近记录: |