虽然乍一看似乎很想
synchronized在默认方法上支持修饰符，但事实证明这样做很危险，因此被禁止。
同步方法是一种方法的简写，该方法的行为就像将整个主体包围在一个
synchronized块中，该块的锁定对象是接收者。将这种语义扩展到默认方法似乎也很明智。毕竟，它们也是带有接收器的实例方法。（请注意，
synchronized方法完全是语法优化；不需要它们，它们比相应的
synchronized块更紧凑。有一个合理的论点是，这首先是一个过早的语法优化，并且同步方法造成的问题比他们解决的问题还多，但那艘船航行了很久。）
那么，为什么会有危险呢？同步与锁定有关。锁定是关于协调对可变状态的共享访问。每个对象都应具有一个同步策略，该策略可以确定哪些锁可以保护哪些状态变量。（请参阅《Java并发实践》第2.4节。）
许多对象将 Java监视器模式 （JCiP
4.1）用作其同步策略，其中对象的状态由其内部锁定来保护。这种模式没有什么魔术或特殊之处，但是它很方便，并且
synchronized在方法上使用关键字隐式地采用了这种模式。
拥有状态的类就是确定该对象的同步策略的类。但是接口并不拥有它们所混入的对象的状态。因此，在接口中使用同步方法假设一种特定的同步策略，但是您没有合理的假设基础，因此很可能是这样使用同步不会提供任何额外的线程安全性（您可能在错误的锁上进行同步）。这会给您一种错误的信心，即您对线程安全已做过一些事情，并且没有错误消息告诉您您采用了错误的同步策略。
很难始终如一地维护单个源文件的同步策略。确保子类正确遵守其父类定义的同步策略甚至更加困难。在这样的松散耦合的类（一个接口以及可能实现它的许多类）之间尝试这样做几乎是不可能的，而且容易出错。
考虑到所有这些反对意见，那将是什么理由呢？似乎它们主要是关于使接口的行为更像特征。尽管这是可以理解的愿望，但是默认方法的设计中心是接口演变，而不是“特质”。我们力求做到这两个方面能够始终如一地实现，但是当一个与另一个发生冲突时，我们必须选择支持主要的设计目标。
