Java多线程并发修改共享可变状态时,因非原子操作易引发数据不一致;需用synchronized、Atomic类、Lock或线程安全容器等方案保障原子性与可见性。

Java 中多个线程并发修改同一个对象的属性时,若不加控制,极易导致数据不一致、丢失更新、脏读等问题。核心在于:**共享可变状态 + 非原子操作 = 线程安全风险**。关键不是“能不能改”,而是“如何安全地改”。
明确哪些操作天然不安全
以下常见场景在多线程下默认不是线程安全的:
- 对普通成员变量(如 int count;)执行 count++(读-改-写三步,非原子)
- 对 ArrayList、HashMap 等非线程安全集合进行增删查改
- 多个字段存在逻辑依赖(如账户余额和交易流水号需同步更新),仅锁单个字段无效
- 使用 volatile 修饰变量只能保证可见性与禁止重排序,不能保证复合操作的原子性(如 i++)
常用且实用的线程安全方案
根据场景选择合适方式,避免过度同步影响性能:
将后端 Java 接口文档转换为前端 TypeScript 类型定义(interface / type)。输入:飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出:包含请求参数与响应结果的 .md 文件,含完整 JSDoc 注释。触发关键词:Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
-
用 synchronized 锁住临界区:最直接。可修饰实例方法(锁 this)、静态方法(锁 Class 对象),或用同步代码块精确锁定共享资源对象(推荐)
示例:synchronized(this) { balance += amount; } -
用 java.util.concurrent.atomic 包下的原子类:适合简单数值/引用更新,无锁、高性能
如 AtomicInteger、AtomicReference,支持 compareAndSet() 等原子操作 -
用显式 Lock(如 ReentrantLock):比 synchronized 更灵活(可尝试获取、可中断、支持条件队列)
注意必须在 finally 块中 unlock(),否则易死锁 - 用线程安全容器替代:如 ConcurrentHashMap 替代 HashMap,CopyOnWriteArrayList 替代 ArrayList(适合读多写少)
避免常见误区
实际开发中容易踩的坑:
- 只给 getter/setter 加 synchronized,但业务逻辑跨多个方法调用——仍可能出错,需扩大同步范围或用组合锁
- 用 new Object() 作为锁对象,每次创建新实例 → 锁失效;应确保所有线程竞争同一把锁(如用 this、private final Object lock = new Object())
- 在 synchronized 方法中调用外部可变对象的方法(如传入的 callback.run()),可能引发锁外逃和死锁
- 误以为局部变量或 ThreadLocal 就能解决所有问题——它们解决的是“数据隔离”,而非“共享修改”的协调
一个最小可运行示例
模拟两个线程同时对账户余额做+10操作各100次:
class Account {
private int balance = 0;
private final Object lock = new Object();
void deposit(int amount) {
synchronized (lock) {
balance += amount; // 原子性保障
}
}
int getBalance() {
synchronized (lock) {
return balance;
}
}
}
// 启动两个线程调用 deposit(10) × 100 → 最终 balance = 2000(确定结果)
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










