面试考察的是真实场景经验而非背诵，核心能力包括：线程安全三要素（原子性、可见性、有序性）的落地与修复；阻塞队列相比wait/notify的优势及juc实践；线程池显式构造的必要性与参数调优；threadlocal在线程池中未清理导致的数据错乱风险及规避方案。
Java并发编程面试问题不是考背诵，而是考你有没有在真实场景里踩过坑、调过线程 dump、修过时序 bug。下面这些是高频真题背后真正要考察的能力点，按实战逻辑归类整理。
线程安全三要素：原子性、可见性、有序性怎么落地？
面试官问“怎么保证线程安全”，答 synchronized 或 Lock 是及格；答清楚这三点在代码中如何被破坏、又如何被修复，才算过关。
-
原子性：比如i++看似一行，实为读-改-写三步，多线程下会丢失更新。用AtomicInteger.incrementAndGet()或加锁才能真正原子 -
可见性：一个线程改了flag = true，另一个线程可能永远看不到。必须用volatile、synchronized或Lock，否则 JVM 可能从本地缓存读旧值 -
有序性：JVM 和 CPU 可能重排序，比如构造函数里先赋值字段再发布 this 引用，导致其他线程看到半初始化对象。靠volatile写、synchronized块或final字段触发 Happens-Before
阻塞队列 vs. wait/notify：生产者-消费者该选哪个？
手写 wait()/notify() 实现阻塞队列是经典陷阱题——它容易漏唤醒、假唤醒、条件竞争，且无法指定超时。而 JUC 的 BlockingQueue（如 ArrayBlockingQueue、LinkedBlockingQueue）已封装所有边界逻辑。
- 用
put()/take()自动处理阻塞和唤醒，无需手动管理 monitor 锁 -
offer(e, timeout, unit)和poll(timeout, unit)支持优雅降级，避免无限等待 - 注意
LinkedBlockingQueue默认容量是Integer.MAX_VALUE，若生产过快且消费阻塞，可能 OOM
ExecutorService executor = Executors.newFixedThreadPool(2);
BlockingQueue<String> queue = new ArrayBlockingQueue<>(100);
executor.submit(() -> { // 生产者
for (int i = 0; i < 1000; i++) {
try {
queue.put("msg-" + i); // 满时自动阻塞
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
break;
}
}
});
executor.submit(() -> { // 消费者
while (true) {
try {
String msg = queue.take(); // 空时自动阻塞
System.out.println(msg);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
break;
}
}
});
线程池创建：为什么禁止直接用 Executors 工厂方法？
因为它们隐藏了关键参数，极易引发线上事故。比如 newFixedThreadPool(n) 底层用的是无界 LinkedBlockingQueue，任务积压会导致内存溢出；newCachedThreadPool() 允许无限创建线程，CPU 扛不住。
立即学习“Java免费学习笔记（深入）”；
- 正确做法是显式构造
ThreadPoolExecutor，控制corePoolSize、maximumPoolSize、workQueue（建议有界）、RejectedExecutionHandler - CPU 密集型任务：线程数 ≈ CPU 核数；IO 密集型可适当放大（如核数 × 2），但需压测验证
- 务必设置
ThreadFactory命名线程，否则线程 dump 里全是pool-1-thread-1，无法定位归属
ThreadLocal 在线程池中不清理会导致什么？
这是高危雷区。线程池复用线程，而 ThreadLocal 的值会随线程生命周期延续。如果业务代码往 ThreadLocal 存了数据库连接、用户上下文、事务 ID，下一个任务拿到的可能是上一个请求残留的数据——轻则数据错乱，重则越权访问。
- 每次使用后必须调用
threadLocal.remove()，尤其在 filter / interceptor / finally 块中 - 不要依赖
ThreadLocal的initialValue()自动初始化，它只在首次 get 时触发，复用线程不会再次调用 - 更安全的替代方案：用
MDC（logback）做日志追踪，或把上下文作为参数显式传递
并发编程最难的从来不是 API 调用，而是理解「谁在什么时候看到了什么值」。很多 bug 不是代码写错了，而是对内存模型、调度时机、锁释放顺序的直觉出了偏差。多看 thread dump，少信“应该没问题”。
