本质关系：1:1 映射实现

• 现代 Java 线程（JDK 1.2+）基于操作系统原生线程实现（如 Linux 的 pthread），每个 Java 线程对应一个内核线程。
• 通过 pthread_create 等系统调用创建内核线程，由操作系统调度器（如 Linux CFS）分配 CPU 时间片。例如 new Thread() 会触发 JVM 调用 pthread_create。

核心区别：抽象层级与资源管理

• 调度机制：
  • Java 线程优先级（如 Thread.MAX_PRIORITY）会被映射到操作系统优先级（如 Linux 的 nice 值），映射规则因平台而异。
  • 操作系统可通过 sched_setscheduler() 设置实时调度策略（如 SCHED_FIFO），需 root 权限且影响系统稳定性。
• 状态管理：
  • Java 线程状态（RUNNABLE、BLOCKED）是 JVM 逻辑状态，不完全对应内核线程的 ready 或 waiting 状态。
• 资源开销：Java 线程需额外 JVM 堆内存，上下文切换成本高于原生线程。

历史演变与新型线程

• 绿色线程（JDK 1.2 前）：用户态线程，JVM 自行调度，无法利用多核。
• 虚拟线程（Java 19+）：轻量级用户态线程，由 JVM 调度，多虚拟线程复用少量内核线程，适合高并发 I/O 场景。

开发注意事项

• 线程数量控制：避免过度创建内核线程（受限于 ulimit -u），推荐使用 ThreadPoolExecutor。
• 线程类型选择：
  • CPU 密集型任务：优先传统线程（1:1 模型）。
  • I/O 密集型任务：优先虚拟线程（减少上下文切换）。
• 跨平台差异：Windows 支持 7 级优先级，Linux 优先级范围更窄，需谨慎依赖优先级逻辑。

线程安全问题

• 共享资源竞争：多线程同时修改共享变量（如计数器）会导致数据不一致。
  • 解决方案：使用 synchronized、Lock 或原子类（如 AtomicInteger），或通过线程安全容器（如 ConcurrentHashMap）管理共享数据。
• 不可变对象：优先设计不可变对象（如 String），避免同步开销。

死锁与活锁

• 死锁条件：互斥、持有并等待、不可抢占、循环等待。
  • 预防：按固定顺序获取锁，使用 tryLock() 超时机制，避免嵌套锁。
• 活锁：线程不断重试失败操作（如消息处理冲突），可通过随机退避策略解决。

同步机制的选择

• synchronized：简单但粒度粗，适用于低竞争场景。
• Lock/Condition：更灵活（如可中断、超时），适合高竞争或复杂条件等待。
• CAS 无锁编程：通过 Atomic 类实现，适合高并发但低冲突场景（如计数器）。

资源管理与泄漏

• 线程泄漏：未正确关闭线程池，导致线程持续占用资源。
  • 建议：使用 ExecutorService 并调用 shutdown()，避免手动创建线程。
• 资源未释放：锁或 I/O 资源未在 finally 块中释放，导致死锁或泄漏。

性能与开销

• 上下文切换成本：线程过多会导致 CPU 时间浪费在切换而非任务执行。
  • 优化：根据任务类型（CPU/I/O 密集）调整线程池大小，或使用协程（如虚拟线程）。
• 伪共享（False Sharing）：多个线程修改同一缓存行的不同变量，导致缓存失效。
  • 解决：使用 @Contended 注解或填充字节对齐变量。

内存可见性

• volatile 关键字：确保变量修改对其他线程立即可见，但无法保证原子性。
• happens-before 规则：通过同步操作（如 synchronized、Lock）建立内存屏障，避免指令重排序问题。

异常处理

• 未捕获异常：线程内未捕获的异常会导致线程终止且无日志。
  • 处理：通过 UncaughtExceptionHandler 统一捕获并记录异常。

ThreadLocal 的使用与风险

• 适用场景：保存线程私有数据（如数据库连接、用户会话）。
• 内存泄漏：线程池中线程复用可能导致 ThreadLocal 数据长期未被清理。
  • 解决：使用后调用 remove() 方法清除数据。

并发工具的正确使用

• 并发容器：优先使用 ConcurrentHashMap、CopyOnWriteArrayList 代替同步容器（如 Hashtable）。
• CountDownLatch/CyclicBarrier：协调多线程阶段性任务，避免忙等待。

平台与版本差异

• 虚拟线程（Java 19+）：适用于高并发 I/O 场景，但需注意与传统线程的交互。
• 操作系统限制：Linux 默认线程数限制（ulimit -u），需调整参数支持大规模线程池。

事务型协议方案

• 两阶段提交 (2PC)：协调者与参与者分准备、提交两阶段交互，保证强一致性，但存在单点故障和性能瓶颈。
• 三阶段提交 (3PC)：增加预提交阶段，减少阻塞时间，复杂度更高。
• TCC 模式：通过 Try-Confirm-Cancel 实现柔性事务，需手动补偿逻辑，适合复杂业务。

异步最终一致性方案

• 消息队列：通过 Kafka、RabbitMQ 异步传递数据变更事件，结合重试机制实现最终一致性。
• Saga 模式：拆分长事务为子事务，失败时触发补偿操作，适合订单、支付等链式场景。

锁与校验机制

• 分布式锁：使用 Redis/Zookeeper 实现互斥访问，注意锁超时和死锁问题。
• 数据版本控制：基于时间戳或序列号实现乐观锁（CAS），减少锁竞争。
• 哈希校验：计算数据哈希值，用于快速验证一致性，适用于文件传输。

数据同步策略

• 强一致性复制：采用 Paxos、Raft 协议确保多副本实时同步，适合金融等高要求场景。
• 异步复制：通过日志同步降低延迟，容忍短期不一致，适合跨地域系统。
• 双写策略：主备数据库同时写入，结合冲突检测（如 Last Write Wins）保障一致性。

新型技术方案

• 区块链：基于共识算法（如 PoW/PoS）实现不可篡改账本，适合供应链、版权管理。
• 云原生数据库：如 CockroachDB 支持多活架构和自动分片，内置强一致性。
• 数据网格 (Data Mesh)：通过领域自治和联邦治理实现跨平台一致性，需标准化接口。

实践建议

• 强一致性选 2PC/TCC，最终一致性优先消息队列或 Saga。
• 高并发场景避免锁竞争，采用无锁设计或异步补偿。
• 结合监控告警和自动修复机制，降低不一致风险。

所属类与方法类型

• sleep() 是 Thread 类的静态方法，可直接通过类名调用。
• wait() 是 Object 类的实例方法，必须在同步代码块或方法中调用。

锁的释放行为

• sleep() 不释放持有的锁，其他线程无法进入同步代码块。
• wait() 会释放当前对象的锁，允许其他线程获取锁执行同步代码。

唤醒机制与状态

• sleep() 超时后自动恢复，线程进入 TIMED_WAITING 状态。
• wait() 需通过 notify()/notifyAll() 或超时唤醒：
  • 无超时参数时进入 WAITING 状态。
  • 有超时参数时进入 TIMED_WAITING 状态。

使用场景与异常处理

• sleep() 用于独立延时任务（如定时轮询），需处理 InterruptedException。
• wait() 用于多线程协作（如生产者-消费者模型），需处理 InterruptedException 和 IllegalMonitorStateException（未正确同步时抛出）。

参数与底层实现

• sleep() 支持纳秒级精度参数（实际依赖操作系统调度）。
• wait() 必须通过对象锁调用，支持超时参数（毫秒 + 纳秒）。

核心区别总结

CPU 释放机制

• Thread.sleep() 调用时线程主动让出 CPU 时间片，进入 TIMED_WAITING 状态，操作系统将其移出可运行队列，CPU 资源分配给其他就绪线程。

锁资源的保持

• sleep() 不会释放已持有的锁（如 synchronized 同步块中的锁），其他线程无法获取同一锁。

性能影响与上下文切换

• 短时间频繁调用 sleep()（如毫秒级）会导致高频线程切换，增加 CPU 调度开销。
• 建议：高并发场景优先延长休眠时间（如 10ms 替代 1ms）或使用异步等待（如 CompletableFuture.delay()）。

使用场景建议

• 适用场景：独立延时任务（如定时轮询）、模拟耗时操作、调试。
• 不适用场景：线程协作（需用 wait()/notify()）、高精度实时任务（受操作系统调度影响）。

异常处理

• 必须捕获 InterruptedException，并在捕获后通过 Thread.currentThread().interrupt() 恢复中断状态。

等待/通知机制（wait()/notify()）

• 基于共享对象的监视器锁实现：线程调用 wait() 释放锁并等待，其他线程通过 notify()/notifyAll() 唤醒。
• 适用场景：生产者-消费者模型等需要协调顺序的共享资源操作。
• 注意：必须在 synchronized 代码块内使用，配合 while 循环防止虚假唤醒。

共享变量与 volatile

• 通过共享变量传递数据，volatile 保证可见性但不保证原子性。
• 适用场景：简单状态标志（如线程启停控制）。

Lock 与 Condition

• ReentrantLock 替代 synchronized，Condition 提供多条件队列支持，可精确控制唤醒顺序。

阻塞队列（BlockingQueue）

• 线程安全队列自动处理阻塞逻辑（如空队列阻塞消费者，满队列阻塞生产者）。
• 实现类：ArrayBlockingQueue（固定容量）、LinkedBlockingQueue（可选容量）。
• 适用场景：生产者-消费者模式的数据传递与同步。

并发工具类

• CountDownLatch：主线程等待多个子线程完成任务（如初始化）。
• CyclicBarrier：多线程相互等待至共同点后继续（可重用）。
• Semaphore：控制资源并发访问数（如连接池）。

管道流（PipedInputStream/PipedOutputStream）

• 基于字节流的单向数据传输，适用简单数据传递场景，性能较低。

信号量与原子类

• Semaphore 控制资源访问权限，支持公平/非公平策略。
• AtomicInteger 等原子类实现无锁线程安全计数或状态管理。

并发集合类

• ConcurrentHashMap：分段锁实现的线程安全哈希表，适用于高并发读写（如缓存）。
• CopyOnWriteArrayList：写时复制列表，读多写少场景高效（如监听器列表）。

同步工具类

• CountDownLatch：倒计时门闩，主线程等待多个子任务完成（如系统初始化）。
• CyclicBarrier：可重用屏障，多线程同步至同一阶段（如分批次数据处理）。
• Semaphore：控制并发资源访问数（如连接池限流）。

执行框架类

• ThreadPoolExecutor：灵活配置线程池参数（核心线程数、队列策略等）。
• CompletableFuture：异步编程工具，支持链式调用和组合任务（如并行计算编排）。

原子操作类

• AtomicInteger：基于 CAS 的无锁计数器，高性能并发计数（如请求量统计）。
• AtomicReference：原子更新对象引用（如状态标志的无锁更新）。

锁与条件类

• ReentrantLock：可中断、超时的可重入锁，替代 synchronized。
• StampedLock：乐观读锁，减少读写锁竞争（如读多写少的场景优化）。
• Condition：细粒度条件等待/唤醒，支持多条件队列（如生产者-消费者模型）。

并发队列类

• LinkedBlockingQueue：无界或容量可选阻塞队列（如任务缓冲队列）。
• SynchronousQueue：直接传递任务的队列（如线程池的立即匹配策略）。

互斥锁

• synchronized
  • 特点：JVM 内置锁，自动管理锁的获取与释放，支持可重入。
  • 场景：简单临界区保护（如计数器操作）、单例模式的双重检查锁。
• ReentrantLock
  • 特点：支持可中断锁、公平锁、条件变量，需手动释放锁。
  • 场景：复杂同步需求（如超时控制、多条件判断）。

读写锁

• ReentrantReadWriteLock
  • 特点：读操作共享，写操作独占，提升读多写少场景性能。
  • 场景：缓存系统、配置文件读取、共享文档操作。

无锁机制

• 原子类（AtomicInteger 等）
  • 特点：基于 CAS 实现无锁线程安全操作。
  • 场景：高并发计数（如请求量统计、状态标志更新）。
• volatile
  • 特点：保证变量可见性，需结合锁保证复合操作原子性。
  • 场景：简单状态标志（如线程启停控制）。

乐观锁与悲观锁

• 乐观锁
  • 实现：CAS、版本号机制（如数据库版本字段）。
  • 场景：读多写少场景（如商品库存、点赞计数）。
• 悲观锁
  • 实现：synchronized、ReentrantLock、数据库 SELECT FOR UPDATE。
  • 场景：写操作频繁场景（如金融交易、库存扣减）。

公平锁与非公平锁

• 公平锁
  • 特点：按请求顺序分配锁，避免线程饥饿。
  • 场景：任务调度需严格顺序（如转账操作、数据库连接池）。
• 非公平锁
  • 特点：允许线程插队，吞吐量更高。
  • 场景：高并发读操作（如缓存读取、秒杀系统）。

分段锁与锁优化

• ConcurrentHashMap 的分段锁
  • 特点：锁粒度细化到数据段，减少锁竞争。
  • 场景：高并发哈希表操作。
• 锁粗化与锁消除
  • 特点：JVM 自动优化减少锁开销。
  • 场景：循环内重复加锁、明显无竞争的同步代码。

互斥锁的实践要点

• synchronized 关键字
  • 临界区保护：通过同步方法或代码块保护共享资源（如计数器操作）。
  • 锁对象选择：指定特定对象作为锁缩小粒度（如 synchronized (lockObject)）。
  • 单例模式：双重检查锁定需结合 volatile 避免指令重排序。
• ReentrantLock 高级控制
  • 可中断锁：lockInterruptibly() 避免永久阻塞（如服务端请求处理）。
  • 超时机制：tryLock(1, TimeUnit.SECONDS) 防止死锁（分布式锁场景）。
  • 条件变量：newCondition() 实现线程协作（生产者-消费者模型）。

读写分离场景实践

• ReentrantReadWriteLock
  • 缓存系统：读锁允许多线程并发读，写锁保证数据更新原子性。
  • 配置热更新：读锁读取配置，写锁更新配置实现动态加载。
• StampedLock 性能优化
  • 乐观读模式：tryOptimisticRead() 提升读多写少场景吞吐量（如金融行情读取）。
  • 三维空间计算：保护多个关联变量原子更新（如坐标 x,y,z）。

线程安全工具类应用

• 原子类与无锁编程
  • 计数器场景：AtomicInteger 替代同步锁提升性能 5-10 倍。
  • 状态标志：volatile 修饰简单状态变量（需注意复合操作加锁）。
• 阻塞队列实践
  • 生产者-消费者模型：BlockingQueue 自动处理阻塞与唤醒（如 LinkedBlockingQueue）。

锁使用最佳实践

• 死锁预防
  • 统一加锁顺序：按锁对象 hashCode 排序。
  • 资源限时获取：tryLock 设置超时（推荐 100ms-1s）。
• 性能优化技巧
  • 锁粒度控制：拆分全局锁为分段锁（如 ConcurrentHashMap 桶锁）。
  • 锁消除与粗化：依赖 JVM 自动优化循环内同步代码。
• 资源管理规范
  • try-finally 范式：确保任何路径释放锁（如 finally { lock.unlock() }）。
  • AutoCloseable 集成：支持 try-with-resources 自动释放锁。

典型场景锁选型参考

• 简单临界区：synchronized（单例模式、计数器）。
• 超时/中断控制：ReentrantLock（分布式任务调度）。
• 读多写少（>10:1）：ReentrantReadWriteLock（文档协作系统）。
• 极高读取并发：StampedLock（实时行情推送）。
• 无数据竞争：原子类（请求统计、ID 生成器）。
• 线程协作：Condition + ReentrantLock（订单状态机）。

显式锁（ReentrantLock）

• 手动控制锁的获取与释放（lock()/unlock()），支持公平锁和非公平锁模式。
• 特性：
  • 超时获取（tryLock）和可中断锁（lockInterruptibly）。
  • 多条件变量（Condition）实现精准线程唤醒。
• 场景：高并发资源保护（如转账逻辑）、公平调度系统。

原子操作类（Atomic 类）

• 使用 AtomicInteger、AtomicReference 等通过 CAS 保证单变量原子性。
• 场景：简单计数器、状态标志（如 volatile + AtomicBoolean）。

信号量（Semaphore）

• 通过计数器控制资源并发访问数（acquire()/release()）。
• 场景：数据库连接池限制、并发下载流量控制。

读写锁（ReentrantReadWriteLock）

• 读锁共享，写锁独占。
• 场景：读多写少的配置管理、缓存系统热更新。

线程本地存储（ThreadLocal）

• 为每个线程创建变量副本，避免共享变量同步问题。
• 场景：数据库连接管理、线程不安全工具类（如日期格式化）。

条件变量（Condition）

• 配合锁实现精准唤醒（await()/signal()）。
• 场景：生产者-消费者模型中的满/空队列分离控制。

volatile 关键字

• 保证变量可见性和禁止指令重排序。
• 场景：状态标志（任务终止标记）、双重检查锁定单例模式。

阻塞队列（BlockingQueue）

• 内置线程安全机制，自动处理阻塞与唤醒（put()/take()）。
• 实现：ArrayBlockingQueue（任务调度）、LinkedBlockingQueue（日志异步处理）。

实现机制

• synchronized：基于 JVM 的监视器锁（Monitor），通过对象头管理锁状态，自动处理加锁与释放。
• ReentrantLock：基于 JDK 的 Lock 接口，依赖 AQS 队列和 CAS 操作，需显式调用 lock()/unlock()。

功能特性

• 锁类型
  • synchronized：仅非公平锁，线程获取顺序随机。
  • ReentrantLock：支持公平锁（按请求顺序）和非公平锁（默认）。
• 中断与超时
  • ReentrantLock：支持 lockInterruptibly() 响应中断，tryLock(timeout) 超时机制。
  • synchronized：线程阻塞后无法中断，可能导致死锁。
• 条件变量
  • ReentrantLock：通过 newCondition() 创建多个 Condition 实现精准唤醒（如生产者-消费者模型）。
  • synchronized：仅支持 wait()/notify() 单路通知。

性能与优化

• 低竞争场景：synchronized 因偏向锁、轻量级锁优化性能接近 ReentrantLock。
• 高并发场景：ReentrantLock 非公平锁通过 CAS 减少线程切换，性能更优；synchronized 升级为重量级锁后开销大。

使用方式

• synchronized：语法简洁，自动释放锁，适用于方法或代码块同步。
• ReentrantLock：需显式调用 lock()/unlock()，支持 tryLock() 和超时机制，结合 try-finally 确保释放。

适用场景

• synchronized：简单同步需求（实例变量保护）、低竞争场景、快速开发。
• ReentrantLock：复杂同步逻辑（公平锁、中断响应）、高并发优化、多条件协作（任务调度优先级控制）。

锁的释放与可重入性

• synchronized：可重入且自动释放锁，JVM 在同步代码结束时解锁。
• ReentrantLock：可重入但需手动释放，未正确 unlock() 可能导致死锁。

注意事项

• 锁粒度：synchronized 静态方法锁定类对象可能影响性能，ReentrantLock 可通过细粒度条件优化。
• 死锁预防：ReentrantLock 的 tryLock() 和超时机制减少死锁概率，synchronized 需避免嵌套锁。
• 锁升级机制：synchronized 从偏向锁逐步升级为重量级锁，ReentrantLock 优化需开发者控制。

底层实现的依赖关系

• CAS 是 AQS 的原子操作基础
  • AQS 通过 compareAndSetState() 方法实现 state 的原子更新（如获取锁时从 0 改为 1）。
  • CLH 队列的节点插入与删除（如 enq() 方法）依赖 CAS 保证线程安全。

协同应用的场景

• 锁的公平性与非公平性实现
  • 非公平锁：直接通过 CAS 抢占 state（如 ReentrantLock 默认模式）。
  • 公平锁：在 tryAcquire() 中先检查队列状态，再通过 CAS 修改 state。
• 资源释放与唤醒机制
  • AQS 的 release() 方法通过 CAS 重置 state，并唤醒队列中的下一个线程。

功能定位的区别

• CAS 的轻量级特性
  • 单变量原子操作（如计数器增减），无需锁机制，适用于低竞争场景。
• AQS 的同步框架特性
  • 管理多线程竞争资源的排队、阻塞与唤醒（如 Semaphore 控制并发数）。
  • 支持复杂同步逻辑（如读写锁分离、条件变量 Condition）。

性能优化的互补性

• CAS 的局限性
  • ABA 问题通过 AtomicStampedReference 解决。
  • 高竞争下自旋开销由 AQS 队列阻塞机制缓解。
• AQS 的扩展性
  • 结合 CAS 与队列机制平衡吞吐量（如非公平锁优先 CAS 抢占）。
  • 支持可重入性（通过 state 计数器记录锁持有次数）。

作用

• 线程数据隔离：为每个线程创建独立变量副本，避免多线程共享数据同步开销。
• 上下文管理：存储线程级上下文信息（如用户会话、数据库连接），简化参数传递。

原理

• ThreadLocalMap 结构：每个线程维护一个 ThreadLocalMap，以 ThreadLocal 对象为键（弱引用），用户数据为值（强引用）。
• 操作机制：通过 set()/get() 读写当前线程的 ThreadLocalMap，remove() 清理数据。
• 初始化：使用 withInitial() 设置默认值，首次 get() 触发初始化。

存储的 key-value

• Key：ThreadLocal 实例（弱引用），通过 threadLocalHashCode 唯一标识。
• Value：线程本地数据（强引用），如计数器、会话对象。

潜在问题

• 内存泄漏
  • 原因：Entry 的 key 被 GC 回收后，value 仍占用内存（尤其线程池复用线程时）。
  • 场景：未调用 remove() 导致残留数据长期存在。
• 数据污染：线程池复用线程时，残留数据被后续任务误用。
• 性能开销：哈希冲突使用线性探测法，高并发效率降低。

解决方案

• 及时清理：在 try-finally 中调用 remove() 确保资源释放。
• 弱引用优化：用 static final 修饰 ThreadLocal 实例，减少 key 回收风险。
• 避免大对象：优先存储轻量级数据，大型对象改用外部缓存。
• 数据隔离检查：线程池任务执行前显式清理 ThreadLocal 数据。

编译器优化重排序

• 消除冗余：删除重复计算或无效指令（如未使用的变量赋值）。
• 指令调度：将无数据依赖的指令交错排列以填充 CPU 流水线。
• 循环展开：复制循环体减少分支预测开销。

处理器动态重排序

• 乱序执行（OoOE）
  • 使用重排序缓冲区（ROB）存储未提交指令，通过保留站监控操作数可用性。
• 内存系统优化
  • 写缓冲区（Write Buffer）延迟内存写入，合并多次写操作。
  • 缓存 Bank 划分允许并行访问不同存储单元。

重排序的约束条件

• 数据依赖性限制
  • 真数据依赖（RAW）不可重排，反依赖（WAR）和输出依赖（WAW）可通过寄存器重命名解除。
• 控制依赖性限制
  • 分支预测允许提前执行推测路径指令（预测失败则丢弃结果）。

重排序的动机与效果

• 性能提升机制
  • 减少流水线停顿，隐藏内存延迟，提高缓存命中率。
• 典型优化效果
  • 提升流水线指令吞吐量，通过寄存器重命名实现多指令并行。

重排序引发的问题与解决方案

• 多线程可见性问题
  • 写缓冲区延迟导致读取旧值：使用内存屏障指令（如 x86 的 MFENCE）强制刷新。
• 有序性破坏
  • 对象未初始化被使用：通过 volatile 关键字插入 LoadLoad/StoreStore 屏障。

可见性保证

• volatile：通过内存屏障强制将修改值刷新到主内存，禁止指令重排序（LoadLoad/StoreStore 屏障）。
• synchronized：锁机制强制同步块内变量从主内存读取/刷新。

原子性差异

• volatile：仅保证单次读/写原子性（如 boolean 赋值），不支持复合操作（如 i++）。
• synchronized：通过独占锁保证代码块内所有操作的原子性。

作用范围与实现机制

• volatile：仅修饰变量，基于 JVM 内存模型实现无锁同步。
• synchronized：可修饰方法或代码块，基于对象监视器锁（Monitor）实现互斥访问。

性能与锁机制

• volatile：无锁机制，无线程阻塞，适合高频读操作。
• synchronized：涉及锁获取/释放，可能触发线程阻塞，但 JVM 优化后性能提升（偏向锁、轻量级锁）。

适用场景

• volatile：单例模式 DCL、状态标志（如 isRunning）、硬件寄存器访问。
• synchronized：需要原子性的复合操作（如计数器递增）、临界区资源保护（如文件读写）。

有序性处理

• volatile：通过内存屏障禁止指令重排序，保证操作顺序与代码一致。
• synchronized：隐式通过锁保证有序性，无法主动禁止重排序。

可重入性与灵活性

• volatile：不支持重入，仅适用于简单变量同步。
• synchronized：支持可重入锁（如递归调用）。

AbortPolicy (中止策略)

• 行为：直接抛出 RejectedExecutionException 异常中断任务提交。
• 适用场景：对任务完整性要求极高的场景（如金融交易），需配合异常捕获机制。
• 风险：未捕获异常可能导致程序中断。

CallerRunsPolicy (调用者运行策略)

• 行为：将任务回退到提交任务的线程（如主线程）直接执行。
• 适用场景：生产速度远高于消费速度时自然限流，允许短暂阻塞主线程的非实时任务。
• 注意事项：避免关键线程（如 UI 主线程）被阻塞。

DiscardPolicy (静默丢弃策略)

• 行为：无提示丢弃新任务，不抛异常也不执行。
• 适用场景：允许任务丢失的非关键场景（如实时监控采样）。
• 风险：需监控丢弃任务量，避免数据不一致。

DiscardOldestPolicy (弃老策略)

• 行为：丢弃队列中最旧任务，重试提交当前新任务。
• 适用场景：新任务优先级高于旧任务（如实时消息覆盖历史数据）。
• 风险：可能丢弃重要旧任务，需评估业务容忍度。

自定义拒绝策略

• 实现方式：实现 RejectedExecutionHandler 接口扩展逻辑。
• 典型方案：
  • 持久化存储：任务存入数据库/Redis 后续处理。
  • 异步重试：延迟后重新提交或转移至备用线程池。
  • 告警通知：触发监控并记录任务详情。
• 适用场景：需保障任务最终执行的业务（如订单支付）。

策略选择原则

• 任务重要性：关键任务优先用 CallerRunsPolicy 或自定义策略。
• 系统容忍度：允许丢失用 DiscardPolicy，需时效性用 DiscardOldestPolicy。
• 资源限制：内存敏感场景避免无界队列，明确队列容量。
• 监控配套：静默丢弃策略需加强队列长度和拒绝次数监控。

可以设置但需谨慎权衡

• 技术上允许将核心线程数设为 0，线程池通过非核心线程处理任务。
• 任务提交逻辑：
  • 当前工作线程为 0 时创建非核心线程执行任务。
  • 已有非核心线程且队列未满时，任务入队等待。
• 适用场景：
  • 极低频非关键任务（如日志清理），避免常驻线程占用资源。
  • 突发流量后需快速释放资源的临时任务（如活动促销统计）。

潜在风险与限制

• 线程无法复用：每次任务可能触发新建线程，增加创建/销毁开销。
• 队列容量敏感
  • 无界队列（如 LinkedBlockingQueue）可能导致 OOM。
  • 有界队列需精确设置容量防止任务堆积。
• 响应延迟：首次任务需等待线程创建，影响实时性要求高的场景。

替代优化方案

• 动态核心线程：通过 allowCoreThreadTimeOut(true) 允许核心线程超时回收，保留复用能力。
• 弹性线程池
  • 根据 QPS 动态调整 corePoolSize（如夜间降为 0，高峰期恢复）。
  • 结合监控告警自动扩容/缩容（如 Prometheus + 动态配置中心）。

实践建议

• 稳定性要求高的系统（如支付服务）避免核心线程数为 0，优先动态调整策略。
• 测试环境需验证线程创建速率和任务响应时间，防止生产环境性能瓶颈。

shutdown() 的作用

• 新任务处理：立即拒绝新任务提交，触发拒绝策略（如抛 RejectedExecutionException）。
• 现有任务处理：等待已提交任务（包括执行中和队列中的）全部完成。
• 状态变化：将线程池状态从 RUNNING 变为 SHUTDOWN，最终进入 TERMINATED。
• 线程中断：仅中断空闲线程，不干扰执行中的任务。

shutdownNow() 的作用

• 新任务处理：立即拒绝新任务提交。
• 现有任务处理
  • 尝试中断所有正在执行的任务（通过 interrupt()）。
  • 清空队列并返回未执行任务列表（List<Runnable>）。
• 状态变化：将状态从 RUNNING 改为 STOP，最终进入 TERMINATED。
• 线程中断：强制中断所有工作线程，无论是否空闲。

关键差异对比

• 新任务处理：均拒绝新任务。
• 现有任务处理
  • shutdown() 等待任务完成。
  • shutdownNow() 中断任务并丢弃未执行任务。
• 线程中断范围
  • shutdown() 仅中断空闲线程。
  • shutdownNow() 中断所有线程。
• 返回值
  • shutdown() 无返回值。
  • shutdownNow() 返回未执行任务列表。
• 适用场景
  • shutdown()：优雅停机（如服务正常退出）。
  • shutdownNow()：紧急终止（如死锁或资源耗尽）。

使用建议

• 组合调用：先调用 shutdown() 等待任务完成，若超时未终止再调用 shutdownNow()，需捕获 InterruptedException 并处理。
• 任务容错设计：在任务代码中检查中断状态，确保能响应中断请求。

注意事项

• 资源泄漏：未正确关闭线程池可能导致线程和资源（如数据库连接）无法释放。
• 队列影响
  • 无界队列使用 shutdown() 可能导致 OOM。
  • shutdownNow() 清空队列可缓解内存压力。

通过 Future 对象取消任务

• 提交任务后返回 Future 对象，调用 cancel(boolean mayInterruptIfRunning) 可尝试取消任务。
• 参数作用
  • mayInterruptIfRunning = true：若任务已执行，触发线程中断（需任务代码响应中断）。
  • mayInterruptIfRunning = false：仅取消未开始执行的任务。
• 返回值
  • true：任务成功取消（未开始或已响应中断）。
  • false：任务已完成或无法取消。

不同任务状态下的撤回结果

• 任务未开始执行：cancel() 可成功移除队列中的任务。
• 任务正在执行：依赖任务代码的中断响应逻辑（如检查 isInterrupted() 或捕获 InterruptedException）。
• 任务已完成：无法撤回，cancel() 返回 false。

线程池实现的影响

• ThreadPoolExecutor 的局限性
  • 无界队列（如 LinkedBlockingQueue）中的任务无法直接撤回，需通过 Future.cancel()。
  • remove(Runnable task) 方法可移除队列中未执行的任务，但需明确任务引用。
• 定时任务（ScheduledThreadPool）
  • ScheduledFuture.cancel() 可终止周期性任务，已开始的单次任务仍需中断响应逻辑。

实践建议

• 代码容错设计：任务逻辑中定期检查中断状态，确保能响应取消请求。
• 组合关闭策略
  • 先调用 shutdown() 等待任务完成，超时后使用 shutdownNow() 强制终止。
• 避免无界队列：使用有界队列（如 ArrayBlockingQueue）减少无法撤回任务的风险。

基础同步锁方案

• 同步机制：使用 synchronized 保证原子操作，避免竞态条件。
• 双重检查机制
  • 外层 while(num <= 100) 控制整体循环。
  • 内层 while(num%2 ==0) 实现条件等待。
• 线程协作
  • wait() 释放锁并暂停当前线程。
  • notify() 唤醒等待线程。

标志位优化方案

• 显式状态控制：通过 isOddTurn 布尔标志管理奇偶切换。
• 性能优化
  • 避免频繁计算奇偶性，提升执行效率。
  • 便于扩展多线程交替逻辑（如三线程 ABC 交替）。

高级锁机制方案

• 精细控制：使用 ReentrantLock 替代 synchronized，提供更灵活的锁管理。
• 条件队列
  • 通过 Condition 对象（oddCond 和 evenCond）分别管理奇偶线程等待队列。
  • signal() 精准唤醒目标线程。

实现要点总结

• 同步机制选择：简单场景用 synchronized，复杂场景用 ReentrantLock。
• 条件判断：必须使用 while 循环检查条件，避免虚假唤醒。
• 数值递增：在同步代码块内完成修改，保证原子性。
• 终止条件：循环外设置退出检测（如 num > 100），防止数值越界。
• 异常处理：捕获 InterruptedException 并确保锁最终释放。

调试与扩展

• 调试建议
  • 通过 Thread.setName() 设置线程名称，便于日志追踪。
  • 使用 jstack 检测死锁，VisualVM 监控线程状态。
• 扩展应用场景
  • 多阶段交替：修改为三个线程交替打印（如 ABCABC 序列）。
  • 动态调整上限：通过 volatile 变量实现运行时修改最大值。
  • 分布式扩展：结合消息队列（如 Kafka）实现跨进程顺序控制。

解决指令重排序问题

• 对象实例化操作 instance = new Singleton() 在 JVM 中分为三步：
  • 分配内存空间
  • 调用构造函数初始化对象
  • 将对象引用赋值给变量
• 无 volatile 时可能发生指令重排序（如顺序变为 ①→③→②），导致其他线程获取未初始化完成的实例。
• volatile 通过内存屏障禁止指令重排序，确保初始化顺序为 ①→②→③，避免「半初始化」对象。

保证可见性

• 当首个线程完成实例化后，volatile 强制将最新值刷新到主内存，其他线程立即感知 instance 非空，避免重复创建。
• 仅用 synchronized 时，其他线程可能因本地缓存未更新而误判 instance 为空。

双重检查锁定的完整性

• 第一次判空：减少锁竞争，仅实例未初始化时进入同步块。
• 第二次判空：防止多个线程通过第一次检查后重复初始化。
• volatile 配合：确保第二次判空时读取最新值，避免指令重排序或可见性问题导致判空失效。

性能与安全的平衡

• synchronized 保证原子性，但无法单独解决指令重排序和可见性问题。
• volatile 以较低性能代价（内存屏障）补充 synchronized 的不足，使 DCL 单例高效且线程安全。

使用 CountDownLatch

• 核心机制：创建初始值为 3 的计数器，三个线程执行完毕后调用 countDown() 减少计数。
• 等待线程：通过 await() 阻塞至计数器归零后执行后续任务。

线程 Join 方法

• 实现方式：在等待线程中依次调用三个并发线程的 join()，使其阻塞直至所有目标线程结束。
• 注意事项
  • 需按顺序先启动并发线程再启动等待线程。
  • 适用于简单场景，代码耦合度较高。

CompletableFuture 组合

• 核心方法：通过 CompletableFuture.allOf() 等待所有异步任务完成。
• 优势：支持异步任务组合，可链式调用后续操作（如 thenRun()）。

线程池与 awaitTermination

• 实现流程
  • 将三个任务提交至线程池。
  • 调用 shutdown() 关闭线程池后，使用 awaitTermination() 等待任务完成。
• 优势：适合批量任务管理，可设置超时时间防止无限等待。

信号量 (Semaphore)

• 控制逻辑
  • 初始化三个许可，等待线程需调用 acquire(3) 获取全部许可后执行。
  • 每个并发线程执行后调用 release() 释放许可。
• 适用场景：支持动态调整等待线程数量，灵活性较高。

方案选择建议

• 轻量级场景：优先选择 CountDownLatch 或 CompletableFuture，代码简洁且控制精准。
• 批量任务管理：推荐线程池的 awaitTermination，便于扩展和资源管理。
• 动态调整需求：使用 Semaphore 可灵活控制许可数量。
• 异常处理：所有方案需注意线程泄漏和死锁风险，确保资源释放。

可能的取值范围

• 最低结果：0（极端情况下所有加操作被覆盖）。
• 最高结果：100（理想线程串行执行）。
• 实际常见值：50~100 之间波动，可能更小（如交替执行多次覆盖修改）。

原因分析

• 非原子操作：n += 1 包含读取、修改、写入三步，可能被线程切换打断。
  • 示例：线程 A 读 n=0 → 线程 B 读 n=0 → 均写入 n=1，导致两次操作仅生效一次。
• 缓存可见性问题：多核 CPU 缓存未同步，线程可能读取旧值（如线程 A 修改后未刷回主存，线程 B 仍用 n=0 计算）。
• 指令重排序：编译器或 CPU 调整指令顺序，延迟写入操作加剧数据不一致。

解决方案

• 同步锁
  • 使用 synchronized 或 ReentrantLock 保证临界区代码原子性。
• 原子变量
  • 用 AtomicInteger 替代普通整型变量，通过 incrementAndGet() 的 CAS 机制保证原子性，性能优于锁。
• 线程安全容器
  • 如 ConcurrentHashMap 提供细粒度并发控制，但本场景更适用原子变量。

FixedThreadPool (固定大小线程池)

• 核心参数：corePoolSize = maximumPoolSize，无界队列 LinkedBlockingQueue。
• 特点：线程数固定，适用于任务量稳定场景（如 Web 服务器请求处理）。
• 风险：无界队列可能导致 OOM。

CachedThreadPool (可缓存线程池)

• 核心参数：核心线程数 0，最大线程数 Integer.MAX_VALUE，同步队列 SynchronousQueue。
• 特点：动态扩容线程，空闲线程 60 秒回收（适合短期异步任务）。
• 风险：线程过多可能耗尽资源。

SingleThreadExecutor (单线程池)

• 核心参数：核心线程数 1，无界队列 LinkedBlockingQueue。
• 特点：保证任务顺序执行（如日志处理、数据库操作）。

ScheduledThreadPool (定时任务线程池)

• 核心参数：固定核心线程数，延迟队列 DelayedWorkQueue。
• 特点：支持延时/周期性任务（如定时备份、心跳检测）。

WorkStealingPool (工作窃取线程池)

• 核心参数：基于 ForkJoinPool，默认线程数等于 CPU 核数。
• 特点：任务窃取机制，适合并行计算（如分治算法、图像处理）。

自定义线程池

• 核心参数：通过 ThreadPoolExecutor 定制核心线程数、队列类型及拒绝策略。
• 适用场景：高并发系统灵活平衡资源与效率。

其他补充

• ForkJoinPool：专为分治任务设计（如递归计算、大规模数据处理）。
• 拒绝策略：支持 AbortPolicy（抛异常）或 DiscardOldestPolicy（丢弃旧任务）等。

corePoolSize (核心线程数)

• 线程池保持活跃的最小线程数，空闲时不会被销毁（除非设置 allowCoreThreadTimeOut=true）。
• 新任务提交时优先创建核心线程处理，直到达到阈值。

maximumPoolSize (最大线程数)

• 允许创建的最大线程总数（核心线程 + 非核心线程）。
• 当队列已满且线程数小于该值时，创建非核心线程。

keepAliveTime (空闲线程存活时间)

• 非核心线程空闲时的最大存活时间，超时后销毁。
• 与 unit 配合使用，默认不影响核心线程。

unit (时间单位)

• 定义 keepAliveTime 的时间单位（如秒、毫秒）。

workQueue (任务队列)

• 存储待执行任务的阻塞队列，影响任务调度逻辑。
• 常见类型：
  • LinkedBlockingQueue（无界队列，可能 OOM）。
  • ArrayBlockingQueue（有界队列，推荐使用）。
  • SynchronousQueue（直接传递任务）。

threadFactory (线程工厂)

• 自定义线程创建方式（命名规则、优先级、守护线程属性）。
• 默认使用 Executors.defaultThreadFactory()。

handler (拒绝策略)

• 线程和队列均满时处理新任务的策略。
• 常用策略：
  • AbortPolicy（默认，抛异常）。
  • CallerRunsPolicy（提交线程直接执行）。
  • DiscardPolicy（静默丢弃）。
  • DiscardOldestPolicy（丢弃最旧任务）。

注意事项

• 队列选择原则：
  • CPU 密集型任务推荐有界队列（如 ArrayBlockingQueue）。
  • I/O 密集型任务可考虑无界队列（需防范 OOM）。
• 参数联动规则：
  • 仅当 workQueue 已满且线程数 < maximumPoolSize 时创建非核心线程。
  • 使用无界队列时 maximumPoolSize 无效。
• 推荐实践：手动创建 ThreadPoolExecutor 控制队列边界，避免使用 Executors 默认实现。

任务类型决定核心线程数

• CPU 密集型任务（如加密计算）：corePoolSize = CPU 核数 + 1（如 8 核设为 9 线程）。
• I/O 密集型任务（如网络请求）：corePoolSize ≈ 2 * CPU 核数（如 8 核设为 16）。
• 混合型任务：corePoolSize = Ncpu * Ucpu * (1 + W/C)，其中 W 为任务等待时间，C 为计算时间。

队列选择与容量设计

• 无界队列（LinkedBlockingQueue）：适用短耗时任务，明确设置容量防止 OOM（如 LinkedBlockingQueue(2000)）。
• 有界队列（ArrayBlockingQueue）：容量计算为 (corePoolSize / 任务平均耗时) * 最大容忍响应时间。
• 同步队列（SynchronousQueue）：需高实时性，搭配 maximumPoolSize 设为较大值（如 50-100）。

线程池扩容与收缩规则

• 最大线程数：通常设为核心数的 1.5-3 倍（如电商场景核心 85，最大 150）。
• 空闲线程回收：keepAliveTime 设为 30-60 秒，突发流量可延长至 2-5 分钟。
• 动态调整：根据 QPS 监控自动扩容（新核心数 = 当前 QPS * 平均耗时 / 1000 * 0.8）。

拒绝策略与容错机制

• CallerRunsPolicy：允许主线程降级处理（如日志记录）。
• DiscardOldestPolicy：新任务优先级高（如实时消息覆盖）。
• 自定义策略：
  • 持久化存储：任务存数据库/Redis 后续处理。
  • 异步重试：延迟后提交或转移至备用线程池。

监控与调优实践

• 监控指标：活跃线程数、队列堆积量、任务平均耗时（推荐 Prometheus 实时监控）。
• 压测验证：某电商优化后 QPS 从 4200 提升至 8500，错误率从 15% 降至 0.2%。
• 弹性设计：容器水平扩容（如 K8s）与线程池参数调优结合应对突发流量。

避坑指南

• 避免 corePoolSize = maximumPoolSize（丧失突发能力）。
• 明确队列容量（禁用默认无界队列）。
• CPU 密集型任务勿用 CallerRunsPolicy（可能阻塞主线程）。

核心组成与初始化

• 线程池管理器：负责创建、销毁线程及任务调度，维护线程池生命周期。
• 任务队列：存储待执行任务，常用阻塞队列（如 LinkedBlockingQueue），队列满时触发拒绝策略。
• 工作线程：核心线程常驻处理任务，非核心线程队列满时动态创建，空闲超时后销毁。
• 线程工厂与拒绝策略：自定义线程属性（如命名规则），定义队列满时的处理逻辑（如抛异常）。

任务处理流程

• 任务提交：通过 submit() 或 execute() 提交 Runnable/Callable 任务。
• 资源分配
  • 线程数 < 核心线程数：直接创建新线程执行。
  • 核心线程已满：任务入队等待。
  • 队列满且线程数 < 最大线程数：创建救急线程处理。
  • 队列和线程均满：触发拒绝策略（如 AbortPolicy）。
• 任务执行：工作线程从队列取任务执行，完成后等待新任务。

线程池状态管理

• 状态标识：通过 ctl 变量（高3位状态，低29位线程数）维护：
  • RUNNING：正常接收并执行任务。
  • SHUTDOWN：不再接收新任务，处理存量任务。
  • STOP：中断所有任务，丢弃未处理任务。
  • TERMINATED：线程池完全终止。
• 状态转换：shutdown() 进入 SHUTDOWN，shutdownNow() 进入 STOP，完成后转为 TERMINATED。

性能优化机制

• 线程复用：避免频繁创建/销毁，减少上下文切换（每次 1-10 微秒）。
• 动态伸缩：根据任务量调整救急线程数量，空闲超时后回收。
• 队列选择
  • CPU 密集型：有界队列（如 ArrayBlockingQueue）。
  • I/O 密集型：无界队列（如 LinkedBlockingQueue）。
• 拒绝策略适配：电商系统采用 CallerRunsPolicy 由提交线程执行任务。

典型应用场景

• Web 服务器：Tomcat 用固定核心线程数（如200）处理 HTTP 请求。
• 异步任务处理：日志写入用缓存线程池（CachedThreadPool）动态扩容。
• 定时任务调度：ScheduledThreadPool 支持延迟/周期性任务（如数据同步）。
• 数据库连接池：复用连接减少建立开销（类比线程池设计）。

设计目标差异

• Java 线程池：面向 CPU 密集型任务，优先用队列缓冲任务减少线程创建开销。核心线程满后任务入队，队列满时才创建非核心线程。
• Tomcat 线程池：针对 I/O 密集型场景优化，优先创建新线程降低延迟，核心满后直接扩容线程至最大值，队列仅作最后缓冲。

队列行为实现机制

• Java 默认队列：使用 LinkedBlockingQueue，核心线程满后直接入队，无界队列可能导致 OOM。
• Tomcat 自定义队列
  • 重写 offer() 方法：当已提交任务数超过活跃线程数时返回 false 触发创建新线程。
  • 仅在线程达最大值或队列满时才真正入队。

线程创建策略对比

• Java 线程池：严格遵循「核心线程→队列→非核心线程」流程，队列未满不扩容。
• Tomcat 线程池：核心线程满后，若提交任务数大于当前线程数，立即创建新线程直至最大值。

性能与资源权衡

• Java 队列优先：适合耗时长的 CPU 运算任务，减少线程切换损耗。
• Tomcat 线程优先：避免队列延迟，快速响应突发流量（如秒杀请求），默认限制队列长度（acceptCount=100）防 OOM。

参数配置体现差异

• Java 参数：corePoolSize 与 maximumPoolSize 分离，依赖队列容量控制资源。
• Tomcat 参数
  • maxThreads 限制线程总数，acceptCount 限制队列容量。
  • minSpareThreads 预创建核心线程，减少首次请求延迟。

资源耗尽风险

• 无界队列导致 OOM
  • FixedThreadPool 和 SingleThreadExecutor 使用 LinkedBlockingQueue，任务提交速度过快时队列无限堆积可能引发内存溢出。
  • ScheduledThreadPool 的延迟队列容量为 Integer.MAX_VALUE，周期性任务堆积存在 OOM 隐患。
• 无界线程池问题
  • CachedThreadPool 允许创建 Integer.MAX_VALUE 线程，高并发下可能耗尽 CPU/内存资源。

配置灵活性与容错能力不足

• 参数固定化
  • 内置线程池的队列类型、核心线程数等参数无法动态调整，难以适配突发流量或资源敏感型任务。
• 默认拒绝策略单一
  • 默认使用 AbortPolicy（抛异常），缺乏降级、重试等容错机制，可能引发服务雪崩。

可维护性与监控缺陷

• 线程命名模糊
  • 内置线程池生成的线程名称（如 pool-1-thread-n）无业务含义，增加排查难度。
• 缺乏监控支持
  • 无法直接获取活跃线程数、队列堆积量等关键指标，需额外开发监控逻辑。

生产环境最佳实践

• 推荐替代方案
  • 使用 ThreadPoolExecutor 手动配置：
    • 有界队列：如 ArrayBlockingQueue 控制内存风险。
    • 合理线程数：根据 CPU 核数和任务类型（CPU/I/O 密集型）设置 corePoolSize 和 maximumPoolSize。
    • 自定义拒绝策略：结合 CallerRunsPolicy 或降级逻辑（如任务存入外部队列）。
• 线程工厂与命名
  • 自定义 ThreadFactory 为线程添加业务标识，便于日志追踪。
• 生命周期管理
  • 通过 shutdown() 和 shutdownNow() 组合实现优雅关闭，避免线程泄漏。