线程安全问题源于共享变量的非原子读写与内存可见性缺失，需用synchronized、无锁类（如ConcurrentHashMap）、volatile（仅限简单场景）等解决；死锁须按序加锁或超时重试；线程池应手动配置有界队列与合理拒绝策略；wait/notify必须用while循环重检条件并配notifyAll。

线程安全问题：共享变量被意外修改

多个线程同时读写同一个 ArrayList 或普通对象字段时，不加同步会导致数据错乱、丢失更新，甚至 ConcurrentModificationException。这不是偶发 bug，而是内存可见性与原子性缺失的必然结果。

• 用 synchronized 块或方法保护临界区，但注意锁对象是否唯一（比如不要用 this 锁一个可变引用）
• 优先考虑无锁方案：如用 ConcurrentHashMap 替代 HashMap，AtomicInteger 替代 int 计数器
• volatile 只能保证可见性和禁止重排序，不能保证复合操作（如 i++）的原子性

死锁：两个线程互相等待对方释放锁

典型场景是线程 A 持有锁 L1 并尝试获取 L2，同时线程 B 持有 L2 并尝试获取 L1。JVM 不会自动检测或中断，程序会永久挂起。

• 按固定顺序获取锁（例如总是先锁 id 小的对象），避免循环等待
• 使用 tryLock(long, TimeUnit) 设定超时，失败后释放已持锁并重试或退避
• 避免在持有锁时调用外部方法（尤其是不可控的回调），防止隐藏锁依赖

线程池配置不当：OOM 或响应延迟飙升

Executors.newFixedThreadPool(10) 看似稳妥，但若任务阻塞（如等待数据库响应）、队列无界，会导致线程数不变但堆积任务耗尽堆内存；而 newCachedThreadPool() 在高并发下可能创建数千线程，触发系统级资源耗尽。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 明确业务最大并发量和平均响应时间，用 ThreadPoolExecutor 手动构造，设置有界队列（如 ArrayBlockingQueue）
• 拒绝策略别只用默认 AbortPolicy，根据场景选 CallerRunsPolicy（让调用线程自己执行）或自定义降级逻辑
• 监控 getActiveCount()、getQueue().size()，而非仅看 CPU 使用率

虚假唤醒与条件等待失效：wait/notify 的经典陷阱

用 wait() 等待某个条件成立时，如果没用 while 循环重检条件，可能因虚假唤醒或信号丢失导致线程在条件不满足时继续执行，引发逻辑错误。

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

• 永远用 while (condition) { obj.wait(); }，而不是 if
• notify() 只唤醒一个线程，无法保证唤醒的是需要该信号的那个；多数场景应改用 notifyAll()
• 条件变量必须与同一把锁关联，且 wait() 前必须已持有该锁

实际写并发代码时，最难的往往不是语法，而是对“谁在什么时候看到什么值”的精确建模。很多问题在线程数少、负载低时完全不暴露，一上生产就崩。别迷信工具类封装，得清楚 synchronized 底层怎么刷缓存、volatile 怎么插入内存屏障、ForkJoinPool 怎么偷任务——否则调参和排查都靠猜。