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

Java 中多个线程并发修改同一个对象的属性时，若不加控制，极易导致数据不一致、丢失更新、脏读等问题。核心在于：**共享可变状态 + 非原子操作 = 线程安全风险**。关键不是“能不能改”，而是“如何安全地改”。

明确哪些操作天然不安全

以下常见场景在多线程下默认不是线程安全的：

• 对普通成员变量（如 int count;）执行 count++（读-改-写三步，非原子）
• 对 ArrayList、HashMap 等非线程安全集合进行增删查改
• 多个字段存在逻辑依赖（如账户余额和交易流水号需同步更新），仅锁单个字段无效
• 使用 volatile 修饰变量只能保证可见性与禁止重排序，不能保证复合操作的原子性（如 i++）

常用且实用的线程安全方案

根据场景选择合适方式，避免过度同步影响性能：

sc-java-to-ts-interface

将后端 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（适合读多写少）

避免常见误区

实际开发中容易踩的坑：

立即学习“Java免费学习笔记（深入）”；

• 只给 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（确定结果）