并发编程常见陷阱包括：共享变量未加锁导致写丢失和脏读；volatile无法解决复合操作原子性；synchronized需共用锁对象；AtomicInteger比synchronized更优；ArrayList加锁仍不安全；ThreadLocal易内存泄漏须显式remove；FixedThreadPool无界队列易OOM；wait/notify须在synchronized中用while判断条件。
共享变量没加锁，结果和预期完全对不上
多个线程同时读写同一个 int、ArrayList 或自定义对象字段时，不加同步机制，就会出现“写丢失”或“脏读”。这不是偶发 bug，而是 JVM 内存模型决定的必然行为——线程可能一直从本地缓存读值，根本看不到其他线程已写入的新值。
-
volatile只能保证可见性和禁止重排序，不能解决复合操作（如i++）的原子性问题 - 用
synchronized块保护临界区是最直接的方式，但要注意锁对象必须是所有线程共用的同一实例 - 优先考虑
java.util.concurrent.atomic包下的类，比如把int count换成AtomicInteger count，再用count.incrementAndGet() - 别在
ArrayList上简单加个synchronized就以为安全了——它只保护单个方法调用，迭代过程仍可能抛ConcurrentModificationException
误用 ThreadLocal 导致内存泄漏
ThreadLocal 本身不是“线程私有变量”的银弹。它的底层是 Thread 对象持有一个 ThreadLocalMap，而这个 map 的 key 是弱引用的 ThreadLocal 实例。一旦外部强引用丢失，key 被回收，但 value 还留在 map 里——尤其在线程池场景下，线程长期存活，value 就一直占着内存。
- 每次使用完必须显式调用
threadLocal.remove()，不能只靠set(null) - 不要把大对象（比如
StringBuilder、数据库连接）塞进ThreadLocal，除非你确定生命周期可控 - Web 应用中，在 Filter 或 Interceptor 的
finally块里清理ThreadLocal是基本操作
用 Executors.newFixedThreadPool(10) 在生产环境埋雷
这个工厂方法创建的是无界队列（LinkedBlockingQueue）的线程池，任务持续涌入时，队列会无限增长，最终 OOM。它适合教学演示，不适合真实服务。
- 改用
new ThreadPoolExecutor手动构造，明确指定核心线程数、最大线程数、队列容量和拒绝策略 - 拒绝策略别默认用
AbortPolicy（抛RejectedExecutionException），至少选CallerRunsPolicy让调用线程自己执行，起到自然限流作用 - 线程池命名很重要：用
ThreadFactoryBuilder（Guava）或自定义ThreadFactory给线程起名，否则堆栈里全是pool-1-thread-1，查问题时两眼抓瞎
wait() / notify() 不在 synchronized 块里调用
这是运行时异常：直接抛 IllegalMonitorStateException。更隐蔽的问题是，即使语法正确，也常因条件判断逻辑错位导致死锁或假唤醒。
立即学习“Java免费学习笔记（深入）”；
-
wait()必须在synchronized块内，并且锁对象要和notify()用的是同一个 - 永远用
while判断条件，而不是if——因为唤醒后条件可能已变，或者被虚假唤醒（spurious wakeup） - 现代代码尽量避开
wait/notify，改用java.util.concurrent.locks.Condition配合ReentrantLock，API 更清晰，支持多个等待队列 - 如果非要用，确保
notifyAll()是默认选择；只用notify()的前提是：你 100% 确认只有一个线程在等，且唤醒顺序无关紧要
并发问题往往在压测或流量高峰才暴露，但根子埋在最初几行共享变量访问或线程池配置里。最危险的不是报错，而是“看起来正常跑着”，实则数据错乱、内存缓慢上涨、线程卡死——这些都需要从设计阶段就带着“多线程视角”去审视每一处状态共享和资源复用。
