所有静态方法都需同步吗？两种场景下的同步必要性探讨

场景1的同步必要性 #

场景1的静态方法核心是接收外部传入的对象，调用其putInt方法后返回。这里的线程安全风险和该静态方法本身无关，关键取决于两个点：

• 若SomeObject的putInt方法本身是线程安全的（比如内部用ConcurrentHashMap或方法加了synchronized），那无论这个静态方法是否同步，都不会有线程安全问题。
• 若SomeObject的putInt线程不安全，且传入的objectName被多线程共享调用，需要同步的是putInt方法本身，或是在调用这个静态方法的外部逻辑中做同步——给静态方法加synchronized完全没必要，因为静态方法的synchronized锁的是类对象，会导致所有调用该方法的线程排队，哪怕操作的是不同的objectName实例，反而会降低性能。

简言之：场景1的静态方法只是代理调用外部对象的方法，线程安全问题由传入对象的线程安全性和是否被共享决定，不需要给这个静态方法加同步。

场景2的同步误区 #

你认为场景2需要加synchronized是个误解。场景2中是在方法内部创建新的SomeObject实例，这个实例属于当前调用线程的私有对象（每个线程调用都会生成独立实例），只要SomeObject的构造方法和putInt方法在单线程下是安全的，这个静态方法就不需要同步。只有当SomeObject的构造方法依赖了类级别的共享变量（比如静态成员），且这些共享变量的操作线程不安全时，才需要考虑同步，但这属于SomeObject本身的设计问题，和该静态方法无关。

相关设计模式的指导 #

这两种场景属于工厂方法模式的变种，对应不同的线程安全设计原则：

• 场景1类似Builder模式中对已有对象的链式调用，遵循外部对象的线程安全策略，工厂方法仅做操作转发，不负责对象的线程安全保障。
• 场景2是标准的工厂方法，遵循线程封闭原则——每个线程拥有独立的对象实例，避免共享，自然消除线程安全风险。

内容的提问来源于stack exchange，提问作者Mritunjay Choubey