Java并发问题多源于线程安全、内存可见性与锁机制理解偏差：共享变量未同步致数据竞争；volatile不保证复合操作原子性；应优先用AtomicInteger或synchronized/ReentrantLock；避免暴露可变共享对象；锁粒度、锁对象选择需谨慎；须重视happens-before规则与内存可见性；线程池需依场景选队列、设拒绝策略并处理异常。

Java并发编程中，很多问题不是编译不通过，而是运行时偶发、难复现、难定位——根源往往在对线程安全、内存可见性、锁机制的理解偏差或使用不当。

共享变量未加同步导致数据竞争

多个线程同时读写同一个实例变量或静态变量，且未使用synchronized、Lock或原子类保护，极易出现丢失更新、脏读、计算错乱。例如：一个计数器i++看似原子，实则包含读取、加1、写回三步，在多线程下可能被覆盖。

• 用volatile只能保证可见性和禁止重排序，不能保证复合操作的原子性（如i++）
• 简单计数优先选AtomicInteger；复杂逻辑用synchronized或ReentrantLock
• 避免直接暴露可变共享对象引用，尤其集合类——ArrayList、HashMap本身不线程安全

错误地使用synchronized或锁范围不当

synchronized加在方法上容易锁粒度过大；锁对象选择不当（如用this或public对象）会导致意外的锁争用甚至死锁；静态方法锁的是Class对象，与实例锁不互斥。

• 优先锁在私有final对象上，避免锁被外部干扰
• 同步代码块比同步方法更灵活，只锁关键区段
• 不要在synchronized块内调用外部可重入或阻塞的方法（如IO、远程调用），易引发长时间持锁

忽视内存可见性与指令重排序

JVM和CPU为优化性能会重排指令，线程可能看不到其他线程对变量的最新修改。即使加了锁，若没正确建立happens-before关系，仍可能出问题。

• volatile变量写后，后续对该变量的读能看到之前所有写操作（含非volatile字段的写）
• synchronized解锁前的所有写，对后续获取同一锁的线程可见
• 构造器中启动线程并发布this引用，可能导致对象未完全初始化就被其他线程访问

线程池使用不当引发资源耗尽或任务丢失

无界队列（如LinkedBlockingQueue默认容量Integer.MAX_VALUE）+固定线程数，高并发下内存OOM；拒绝策略设置为DiscardPolicy却没日志，任务静默失败；线程池共用在不同生命周期的任务上，造成泄漏。

• 根据业务场景选队列：高吞吐选有界队列+合理拒绝策略（如CallerRunsPolicy）
• 异步任务务必处理异常，否则线程可能因未捕获异常退出，影响线程池稳定性
• 全局线程池建议命名+设置UncaughtExceptionHandler，便于排查

不复杂但容易忽略。关键是理解“谁在共享”、“谁在修改”、“是否需要立即看到”、“锁是否真正互斥”。写完并发代码，多问一遍：这个变量会不会被两个线程同时改？这个结果有没有可能被缓存？这个锁能不能拦住所有路径？