Java并发编程陷阱与避坑攻略

欢迎各位小伙伴来到golang学习网，相聚于此都是缘哈哈哈！今天我给大家带来《Java并发编程常见坑与避坑指南》，这篇文章主要讲到等等知识，如果你对文章相关的知识非常感兴趣或者正在自学，都可以关注我，我会持续更新相关文章！当然，有什么建议也欢迎在评论留言提出！一起学习！

加 synchronized 仍超卖是因为锁对象错误：局部 new 的锁对象不共享，应改用成员变量、类对象或静态锁；volatile 不能保证原子性，count++ 需用 AtomicInteger；SimpleDateFormat 等非线程安全类须替换为线程安全版本；线程池禁用 Executors 默认工厂，需显式配置有界队列和拒绝策略。

为什么加了 synchronized 还是超卖？锁对象选错了

很多新手一看到“线程不安全”，第一反应就是给方法加 synchronized，结果库存还是扣成负数。根本原因不是没加锁，而是锁的对象不对——比如在方法里 new 一个局部 Object lock = new Object()，每个线程都锁自己的对象，等于没锁。

• 正确做法：锁必须是所有线程共享的同一个对象，比如用 private final Object lock = new Object()（成员变量），或直接锁类、锁 this（需确认语义合理）
• 更推荐：对临界资源本身加锁，比如库存扣减逻辑统一锁 StockService.class 或某个静态 lock 对象，避免实例锁被多个对象绕过
• 特别注意：不要锁 String、Integer 等常量池对象，可能被其他代码意外共用，引发隐蔽竞争

volatile 能防重排序，但救不了 i++

volatile 常被误当成“万能线程安全开关”。它确实能保证可见性和禁止指令重排序，但对复合操作毫无作用——count++ 包含读、改、写三步，volatile 只管“读到最新值”，不管“中间会不会被插队”。

• 现象：两个线程同时执行 volatile int count 的 count++，最终结果大概率是 +1 而非 +2
• 修复方案：简单计数优先用 AtomicInteger，比如 count.incrementAndGet()；复杂逻辑才用 synchronized 或 ReentrantLock
• 记住口诀：volatile 是“通知大家我变了”，不是“拦住别人别动我”

SimpleDateFormat、HashMap、StringBuilder —— 看似工具，实为雷区

这些类在单线程下用着顺手，一旦放进多线程环境，立刻暴露非线程安全本质。它们不报错、不抛异常，只是默默给你返回错乱结果，排查起来极难定位。

• SimpleDateFormat：parse/format 内部复用 Calendar 实例，多线程并发调用会相互覆盖状态 → 每次用都 new 一个，或改用 DateTimeFormatter（Java 8+，不可变、线程安全）
• HashMap：并发 put 可能触发扩容时链表成环，导致 get 死循环 → 高并发场景必须换 ConcurrentHashMap，别信“我们并发量小不会出事”
• StringBuilder：内部 char[] 可变，多线程共享 append 会数据错乱 → 改用 StringBuffer（同步方法），或干脆每个线程自己 new 一个

线程池别碰 Executors 的默认工厂

Executors.newFixedThreadPool(10) 看起来干净利落，但背后是无界 LinkedBlockingQueue。流量高峰时任务疯狂堆积，JVM 内存直接爆掉，报 OutOfMemoryError: Java heap space。

• 真实风险：线上服务突然卡死、GC 频繁、监控显示内存持续上涨却找不到泄漏点
• 正确姿势：用 ThreadPoolExecutor 构造函数显式创建，至少指定：核心线程数、最大线程数、有界队列（如 ArrayBlockingQueue）、拒绝策略（如 CallerRunsPolicy）
• 参数参考：CPU 密集型任务，核心线程数 ≈ CPU 核心数；IO 密集型可设为 2–4 倍；队列容量建议设为 100–1000，别用 Integer.MAX_VALUE

并发问题最难的不是写出来，而是“看起来没问题却偶尔出错”。那些只在大促、压测、凌晨三点复现的 bug，往往就藏在锁对象、volatile 误用、共享工具类或线程池配置这些看似微小的选择里。

好了，本文到此结束，带大家了解了《Java并发编程陷阱与避坑攻略》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！