每日Java并发面试系列(5)：基础篇（线程池的核心原理是什么、线程池大小设置为多少更合适、线程池哪几种类型？ThreadLocal为什么会导致内存泄漏？） - 实践

1. 什么是线程池？它的核心原理是什么？

什么是线程池？
线程池是一种基于池化思想管理和使用线程的机制。它内部维护了多个线程，等待着分配由用户提交的并发执行的任务。这避免了频繁创建和销毁线程带来的开销，从而提高了系统的响应速度和资源利用率。

核心原理：
线程池的核心原理是 “线程复用” 和 “资源控制”。

1. 线程复用： 传统的“一任务一线程”模式在任务执行完毕后，线程就会销毁。线程池则让核心线程在执行完任务后不会立即销毁，而是处于等待状态，去获取新的任务来执行。这样就省去了频繁创建和销毁线程的巨大开销（包括系统调用、内存分配、资源初始化等）。
2. 资源控制： 线程池允许我们设置资源池的大小（核心线程数、最大线程数），从而控制并发线程的数量，防止无限制地创建线程导致系统资源被耗尽、CPU过度切换，从而保证系统的稳定性和性能。

线程池的工作流程通常通过其内部的任务队列和一套明确的规则来管理，其核心执行逻辑可以用下图清晰地展示：

---

2. 线程池大小设置为多少更加合适？

这是一个没有固定答案的问题，需要根据具体的应用场景和硬件资源进行权衡和测试。但有一些通用的指导原则和计算公式：

核心考量因素：

• 任务类型：任务是 CPU密集型 还是 IO密集型？
  • CPU密集型：任务主要消耗CPU资源，大部分时间都在进行计算。例如：复杂的数学运算、图像处理、视频编码等。
  • IO密集型：任务大部分时间在等待IO操作（如磁盘读写、网络请求、数据库查询等），CPU空闲时间较多。

经验公式：

• 对于CPU密集型应用：线程数应接近CPU核心数，以避免过多的线程上下文切换开销。
  N_threads = N_cpu + 1 (一个额外的线程用于在发生页错误等暂停时，确保CPU时钟周期不会被浪费)
• 对于IO密集型应用：线程数可以设置得更多一些，因为CPU有很多空闲时间可以去执行其他线程的任务。
  N_threads = N_cpu * U_cpu * (1 + W/C)
  • N_cpu：CPU核心数（可通过 Runtime.getRuntime().availableProcessors() 获取）
  • U_cpu：期望的CPU利用率（0 <= U_cpu <= 1）
  • W/C：等待时间（Wait）与计算时间（Compute）的比值

实际应用：
在实际开发中，通常先使用上述公式得到一个理论值，然后通过压力测试来不断调整和验证，找到最适合当前系统的线程池大小。例如，一个常见的IO密集型应用（如Web服务器）可能会将线程池大小设置为 2 * N_cpu 到 几倍甚至几十倍N_cpu 之间。

---

3. 线程池有哪几种类型？各有什么优缺点？

Java通过 Executors 工厂类提供了几种常见的线程池：

线程池类型	创建方法	工作原理	优点	缺点	适用场景
FixedThreadPool (固定大小线程池)	Executors.newFixedThreadPool(int nThreads)	核心线程数 = 最大线程数，使用无界的 LinkedBlockingQueue。	可以控制最大并发数，提高系统资源利用率。	无界队列，可能堆积大量请求，导致OOM。	适用于处理CPU密集型任务，需要限制线程数量的场景。
CachedThreadPool (可缓存线程池)	Executors.newCachedThreadPool()	核心线程数为0，最大线程数为Integer.MAX_VALUE，使用同步队列 SynchronousQueue。空闲线程存活60秒。	弹性高，应对大量短期异步任务时性能好。	几乎不限制线程数，可能创建过多线程，导致OOM。	适用于执行很多短期异步任务，或负载较轻的服务器。
SingleThreadExecutor (单线程池)	Executors.newSingleThreadExecutor()	核心线程数=最大线程数=1，使用无界的 LinkedBlockingQueue。	保证所有任务按提交顺序串行执行。	无界队列，可能堆积大量请求，导致OOM。	适用于需要顺序执行任务的场景，如日志记录。
ScheduledThreadPool (定时任务线程池)	Executors.newScheduledThreadPool(int coreSize)	核心线程数由参数指定，最大线程数为Integer.MAX_VALUE，使用特殊的 DelayedWorkQueue。	可以定时或周期性执行任务。	同样存在创建过多线程的风险。	执行定时任务、周期性任务，如心跳检测、数据同步等。

重要提示：FixedThreadPool 和 SingleThreadExecutor 因为使用无界队列，CachedThreadPool 和 ScheduledThreadPool 因为最大线程数近乎无限，在任务提交速度远大于处理速度时，都有可能导致内存溢出(OOM)。因此，阿里巴巴Java开发手册强制要求使用 ThreadPoolExecutor 的构造函数来手动创建线程池，以便对线程池参数有更清晰的认识和控制。

---

4. 什么是ThreadLocal？它的实现原理是什么？

什么是ThreadLocal？
ThreadLocal 提供了线程局部变量。这些变量与普通变量不同，每个访问该变量的线程都有自己独立初始化的变量副本，实现了线程间的数据隔离。

实现原理：
ThreadLocal 的核心原理在于每个 Thread 对象内部都维护了一个 ThreadLocalMap 类型的变量 threadLocals。

• ThreadLocalMap 是一个定制化的哈希表，其 Key 是 ThreadLocal 对象本身（使用弱引用），Value 是我们设置的变量副本。
• 当我们调用 threadLocal.set(value) 时，实际上是以当前 ThreadLocal 实例为 Key，将要存储的值作为 Value，存入当前线程的threadLocals 这个 Map 中。
• 当我们调用 threadLocal.get() 时，它首先获取当前线程，然后拿到当前线程的 threadLocals Map，再以当前 ThreadLocal 实例为 Key 去查找对应的 Value。

简单来说，数据并不保存在 ThreadLocal 本身，而是保存在线程的 threadLocals 属性中，由 ThreadLocal 对象作为访问的钥匙。

---

5. ThreadLocal为什么会导致内存泄漏？如何解决的？ThreadLocal的应用场景有哪些？

为什么会导致内存泄漏？
内存泄漏的根本原因是 ThreadLocalMap 中 Entry 的 Key 对 ThreadLocal 实例是弱引用（WeakReference），而 Value 是强引用。

1. 弱引用的Key： 当外界对 ThreadLocal 实例的强引用消失后（例如 threadLocal = null），由于 Entry 的 Key 是弱引用，在下次GC时，这个 Key 会被回收，导致 Entry 的 Key = null。
2. 强引用的Value： 但是，Entry 中的 Value 仍然被一个强引用关联着（通过 Thread -> ThreadLocalMap -> Entry -> Value 这条链）。只要线程不死（例如线程池中的核心线程会常驻），这个 Value 对象就永远不会被回收，从而造成内存泄漏。

如何解决？

1. 良好编程习惯： 在使用完 ThreadLocal 后，必须手动调用其 remove() 方法，将当前线程的 ThreadLocalMap 中对应的 Entry 彻底删除，断开对 Value 的强引用。
2. JDK的设计： ThreadLocal 本身也做了一些努力，在 set(), get(), remove() 方法中，会尝试清理 Key 为 null 的 Entry。但这是一种被动清理，不能完全依赖。

应用场景：

1. 数据库连接（Connection）和事务（Transaction）管理： 将一个连接绑定到当前线程，保证一个事务中的所有操作使用的是同一个连接。
2. Session管理： 在Web开发中，将用户会话信息存储到 ThreadLocal 中，便于在同一次请求的各个层级中获取。
3. 全局参数传递： 避免在方法调用链中层层传递上下文参数（如用户身份信息、语言环境等），直接从 ThreadLocal 中获取。
4. 日期格式化： SimpleDateFormat 是非线程安全的，可以为每个线程创建一个独立的副本。

---

6. CyclicBarrier和CountDownLatch有什么区别？

特性	CountDownLatch	CyclicBarrier
核心机制	一个或多个线程等待一组操作完成	一组线程相互等待，直到所有线程都到达一个公共屏障点
计数器	递减计数，不可重置	递增计数，可重置 (reset())
可重复使用	否，计数器为0后不能再使用	是，通过重置计数器可以循环使用
主要方法	await(), countDown()	await()
等待者	一个或多个等待线程	所有互相等待的线程本身都是屏障点的一部分
常见应用场景	主线程等待多个子线程完成任务后再继续	多线程计算数据，最后合并计算结果；多人游戏等待所有玩家准备完毕

简单比喻：

• CountDownLatch： 就像倒计时发车。司机（主线程）要等所有乘客（多个操作）都上车（countDown()）后，才能发动汽车。
• CyclicBarrier： 就像团队旅行。必须所有成员（所有线程）都到达集合点（await()）后，才能一起出发去下一个景点。

---

7. CopyOnWriteArrayList底层原理是什么？

原理：写时复制（Copy-On-Write）

1. 读取： 所有读取操作（get, iterator）都是直接在一个不变的数组快照上进行的，不需要加锁，性能极高且安全。
2. 写入/修改： 当执行写入操作（add, set, remove）时，它会将底层原有的数组完整地复制（Copy）一份到一个新数组中，然后在这个新数组上进行修改操作。
3. 更新引用： 修改完成后，将底层数组的引用指向这个新数组，替换掉旧的数组。
4. 丢弃旧数据： 旧的数组如果没有被引用，会被GC回收。

优缺点：

• 优点： 读写分离，读操作完全无锁，性能非常高，非常适合读多写少的场景。
• 缺点：
  • 内存占用大： 每次写操作都会复制整个数组，如果数组很大，会对内存造成压力。
  • 数据最终一致性： 读操作读到的是旧数组的数据，无法实时感知到其他线程刚写入的最新数据。不适合对数据实时性要求很高的场景。

---

8. ConcurrentHashMap链表转红黑树为什么是8？

这个设计是基于概率和统计，是时间和空间上的一个权衡。

• 目的： 为了解决哈希冲突严重时，链表过长导致的查询性能从O(1)退化为O(n)的问题。红黑树是一种自平衡的二叉查找树，查询时间复杂度为O(log n)。
• 为什么是8？： 根据泊松分布的概率统计，在理想的哈希函数下，一个哈希桶中节点数量达到8的概率非常低（约为一千万分之六）。这意味着，绝大多数情况下链表长度都不会超过8。选择8这个阈值，可以保证在绝大多数情况下仍然使用链表这种更节省空间的结构，只有在极少数极端情况下，才会转换为红黑树来保证性能。
• 树退化为链表的阈值是6： 为什么不是7？这是为了避免在节点数量在8附近频繁地转换（比如一个节点频繁地插入和删除）。设置一个缓冲区间（6和8之间），可以有效防止因频繁的增删操作导致的不必要的树化和退化，减少性能开销。

---

9. 线程池用完以后是否需要shutdown吗？

是的，强烈建议手动关闭。

如果不关闭，线程池中的核心线程会一直存活，阻止JVM的正常退出。

• shutdown(): 温和的关闭。不再接受新任务，但会等待线程池中已有任务（包括正在执行的和在队列中等待的）执行完毕。
• shutdownNow(): 强制的关闭。尝试中断所有正在执行的任务，不再处理队列中等待的任务，返回尚未执行的任务列表。

最佳实践： 通常在应用程序结束时（例如通过JVM的shutdown hook），调用 shutdown() 来优雅地关闭线程池。

---

10. Java中如何终止一个正在运行的线程？

停止一个线程的正确方式是“通知”它让它自己停下来，而不是强制中断它。

1. 使用标志位（推荐）： 设置一个 volatile 布尔类型的标志位，线程在运行时定期检查这个标志。

   public class MyThread extends Thread {
   private volatile boolean stopped = false;
   public void run() {
   while (!stopped) {
   // ... 执行任务
   }
   }
   public void stopGracefully() {
   this.stopped = true;
   }
   }

2. 使用 interrupt() 方法： 这是一个协作机制。

   • 调用线程的 interrupt() 方法并不是强制终止线程，而是设置线程的中断状态为 true。
   • 被中断的线程需要在自己的代码中检查中断状态并决定如何响应。
   • 如果线程处于阻塞状态（如 sleep, wait, join），它会抛出 InterruptedException，并在捕获异常后重置中断状态。
   • 正确做法： 在任务代码中捕获 InterruptedException 或在循环中检查 Thread.currentThread().isInterrupted()。

   public void run() {
   while (!Thread.currentThread().isInterrupted()) {
   try {
   // ... 执行任务，可能会调用sleep等阻塞方法
   } catch (InterruptedException e) {
   // 捕获异常后，通常有两种选择：
   // 1. 重新设置中断状态，退出循环
   Thread.currentThread().interrupt();
   break;
   // 2. 直接退出循环
   break;
   }
   }
   }

绝对不要使用被废弃的 stop(), suspend(), resume() 方法，因为它们会强制终止线程，立即释放它持有的所有锁，可能导致数据不一致性和死锁问题。