加 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。
立即学习“Java免费学习笔记（深入）”；
- 真实风险：线上服务突然卡死、GC 频繁、监控显示内存持续上涨却找不到泄漏点
- 正确姿势：用
ThreadPoolExecutor构造函数显式创建，至少指定：核心线程数、最大线程数、有界队列（如ArrayBlockingQueue）、拒绝策略（如CallerRunsPolicy） - 参数参考：CPU 密集型任务，核心线程数 ≈ CPU 核心数；IO 密集型可设为 2–4 倍；队列容量建议设为 100–1000，别用 Integer.MAX_VALUE
并发问题最难的不是写出来，而是“看起来没问题却偶尔出错”。那些只在大促、压测、凌晨三点复现的 bug，往往就藏在锁对象、volatile 误用、共享工具类或线程池配置这些看似微小的选择里。
