synchronized 不是方法签名的一部分。但是当我们重写一个方法时，决定被重写的方法是否编译的不仅仅是方法签名。
例如，我们不能添加或扩展已检查的异常
为什么synchronized 在多态中没有作用。 synchronized 方法不应该被覆盖而不放置synchronized。因为使用超类变量的人可能认为所有方法都是线程安全的。
但是应该允许使用synchronized 覆盖非同步方法，因为它正在添加更多功能，但另一方面用户不会遇到任何错误，除了时间延迟。
我正在寻找一个合乎逻辑的解释，它可以阐明“为什么这样设计”。
【问题讨论】：
标签： java multithreading synchronization polymorphism
如果不放置“同步”，则不应覆盖“同步”方法。
错了。基类可能不是线程安全的，但子类可能有自己的同步，例如锁、无锁线程安全数据结构等。并非所有线程安全方法都是同步的，也不是所有同步方法是线程安全的。
同样可以朝另一个方向发展（但可能会违反其他原则，视情况而定）
synchronized 不是面向对象的东西，而是运行时/执行现象，以及实现细节。它所做的只是acquire a monitor 与synchronized(this){ } 相同的方式（或者在java.lang.Class 对象上同步，如果是静态的）。作为一个实现细节，将其暴露给 OOP 考虑是没有意义的。
注意：这并不意味着像@ThreadSafe 这样的编译时注释没有意义。确实如此，因为它引用方法的契约是线程安全的。 synchronized 不会这样做。
【讨论】：
您可以查看JDK-4294756 以了解在不保留synchronized 修饰符的情况下覆盖另一个方法是可以的。此错误报告要求编译器在方法覆盖synchronized 方法但未声明自己synchronized 时显示警告，并且它被关闭为“不会修复”。主要原因如下：
synchronized修饰符的使用，以及其他同步方式 显式的“同步”语句，是实现的一部分 由类表示的抽象，以及捕获的替代实现 在子类中可以使用不同的同步策略以 实现等价语义。例如，考虑以下情况 较大的关键部分（受“同步”语句保护） 非同步方法替换了一个在其受保护的较小方法 整体由同步方法修饰符。
所以没有synchronized 修饰符并不一定意味着该方法不是线程安全的。线程安全可以在方法内部细化。
【讨论】：
让我换一种说法：
假设我们有两个类：
class Foo {
public synchronized void doSomething(...) { ... }
}
class Bar extends Foo {
public void doSomething(...) { ... }
}
Foo 和Bar 是不同的 类。 foo.doSomething(...) 和 bar.doSomething(...) 是不同的方法。
synchronized 关键字不是为了调用者的利益：它没有说明foo.doSomething(...) 做什么。 synchronized 关键字只是该方法实现的细节。
Foo 类需要同步其doSomething(...) 方法，以便在多线程环境中正确履行其 API 契约。 bar.doSomething(...) 方法的实现方式不同，不需要同步。
只要可以在需要 Foo 实例的任何地方使用 Bar 实例，每个人都应该感到高兴。调用者没有理由希望方法同步：调用者应该只希望方法工作。
【讨论】：