多态性本身不涉及线程安全，关键在于共享状态的并发访问控制；需确保多态方法中对可变状态的操作具备原子性、锁粒度匹配语义、避免隐式共享及继承中同步一致性。
多态性本身不直接涉及线程安全，它描述的是“同一接口、不同实现”的行为抽象能力；而多线程环境下对象行为一致性的核心，其实是共享状态的访问控制问题——当多个线程通过多态接口（如父类引用或接口调用）操作同一对象实例时，若该对象内部含有可变的共享状态，就可能因并发修改导致行为不可预期。关键不在“多态”，而在“谁在改、怎么改、改什么”。
下面从实际出发，分几个关键点讲清楚怎么做：
明确多态调用背后的真实对象和状态
多态只是编译期/运行期的方法分派机制，真正执行的是子类重写的方法体。如果这些方法体中访问了共享变量（如实例字段、静态字段、外部缓存等），那它们就是临界资源。例如：
interface Counter { void increment(); int get(); }
class UnsafeCounter implements Counter {
private int count = 0;
public void increment() { count++; } // 非原子，多线程下调用会出错
public int get() { return count; }
}即使通过 Counter c = new UnsafeCounter() 多态调用，c.increment() 仍会破坏一致性——问题根源是 count 的并发读写，不是多态本身。
同步粒度要匹配多态契约的语义边界
若一个接口方法承诺“原子更新+返回新值”（如 int incrementAndGet()），实现类就必须保证该方法整体的原子性，不能只锁部分逻辑。常见做法包括：
- 用
synchronized修饰整个方法（适用于简单场景） - 用
ReentrantLock或AtomicInteger替代普通变量（更高效、可中断、支持CAS） - 若方法组合多个操作（如“先查再删再返”），需用同一把锁保护整个临界段，避免仅锁单步造成逻辑断裂
示例（安全实现）：
class SafeCounter implements Counter {
private final AtomicInteger count = new AtomicInteger(0);
public void increment() { count.incrementAndGet(); }
public int get() { return count.get(); }
}这里多态接口行为稳定，是因为底层状态操作本身就是原子的，与调用方式无关。
避免在多态方法中隐式共享外部可变状态
有些实现会不经意引入跨实例共享的数据，比如：
- 静态集合缓存（
static Map<String, Object> cache） - 单例服务中的非线程安全成员变量
- 使用
ThreadLocal但未正确初始化或清理
这类共享一旦被多个多态对象间接访问，就会绕过各自实例锁的保护。建议：
- 尽量让多态实现类保持无状态或仅持不可变状态
- 若必须共享，明确隔离作用域（如按业务ID分桶加锁）
- 避免在
equals、hashCode、toString等常被框架隐式调用的方法里触发高风险操作
注意继承链中的同步一致性
父类若定义了 synchronized 方法，子类重写时：
- 若不加
synchronized，则失去同步保障（Java 不继承修饰符） - 若加了，但锁对象不统一（如父类锁
this，子类锁new Object()），会导致同步失效 - 推荐显式声明锁对象（如
private final Object lock = new Object();），并在所有相关方法中统一使用
多态让代码灵活，但线程安全得靠设计落实。只要共享状态有明确定义、访问受控、变更原子，无论通过接口、父类还是具体类型调用，行为都一致。
