并发基础与 JMM 入门

并发基础与 JMM 入门
- 并发三大问题
  - 原子性
    - 定义：一个操作要么全部完成，要么完全不完成，中间过程对其他线程不可见
    - 典型反例：i++ 不是原子操作
  - 可见性
    - 定义：一个线程对共享变量的修改，能否及时被其他线程看到
    - 根因
      - CPU 缓存(L1/L2/L3) 与编译器/CPU 重排序
      - 线程可能一直读到自己缓存中的旧值
    - 解决方法
      - volatile: 保证写入对其他线程可见
      - synchronized/Lock：解锁前的写对之后加锁的读可见
      - final：初始化安全
  - 有序性
    - 定义：代码执行顺序是否一定和你写的一样
    - 根因
      - 编译器优化：指令重排(JIT)
      - CPU 乱序执行
- JMM(Java 内存模型)
  - JMM 解决的问题
    - JMM 的目标不是描述硬件，而是给 Java 程序提供一个跨平台一致的并发可见性与有序性规范
    - 规范：
      - 写的代码跑在不同 CPU 上，缓存协议，重排序规则不同
      - JMM 通过 happens-before 规定：只要满足 HB，结果必须可见且有序；不满足 HB，结果运行不可预测
      - HB = Java 并发正确性的法律条文
  - happends-before (HB)
    - HB 是可见性 + 有序性的保证关系
    - A happens-before B
      - A 的结果对 B 可见
      - A 的执行顺序对 B 先行约束
    - 没有 HB，就不保证可见/有序
  - happends-before 规则
    - 程序次序规则
      - 同一个线程能，按程序顺序，前面的操作 HB 后面的操作
    - 监视器锁规则
      - 对同一把锁，unlock HB 之后对同一锁的 lock
    - volatile 变量规则
      - 对同一 volatile 变量，对 volatile 的写 HB 后续对该 volatile 的读
    - 线程启动规则
      - Thread.start() HB 该线程内的所有操作
    - 线程终止规则
      - 线程内所有操作 HB 其他线程成功从 Thread.join() 返回
    - 中断规则
      - 对线程调用 interrupt() HB 被中断线程检测到中断
    - 传递性
      - 若 A HB B，B HB C，则 A HB C
- volatile
  - volatile 保证什么
    - 可见性：写入会刷新到主内存，读取会从主内存获取
    - 有序性：禁止 volatile 写/读周围的特定重排序（内存屏障）
    - 建立 happens-before：写 HB 读
  - volatile 不保证
    - 不保证复合操作原子性
    - 不保证所有代码不重拍：只约束与 volatile 相关的重排边界
  - volatile 的经典使用场景
    - 状态标志：停止线程 volatile boolean stop
    - 单例的安全发布
    - 读多写少的配置刷新
- DLC（双重检查锁）为什么必须加 volatile
  - new Singleton() 在底层上被视为三步：
    - 分配内存
    - 调用构造器初始化对象
    - 把引用赋给 instance
  - 如果发生重排序，可能变为
    - 分配内存
    - 赋引用给 instance
    - 初始化对象
  - 另一个线程看到 instance != null 就返回，但是拿到半初始化对象
  - volatile 禁止这种关键重排并建立 HB，确保安全发布
- final 的初始化安全
  - final 字段在构造完成后有更强的可见性保障

线程模型与线程安全

线程模型与线程安全
- Java 线程模型：Thread/Runnable/Callable/Future
  - 四者关系与使用场景
    - Thread: 线程载体+执行单元
    - Runnable：无返回值、不能抛受检异常
    - Callable: 有返回值，可抛异常（配合 Future）
    - Future：异步结果句柄（拿结果、取消、超时）
    - Thread 是执行容器，Runnable/Callable 是任务；Callable 比 Runnable 多返回值与异常；Future 是任务的控制面板
  - Future API
    - get()：阻塞拿结果
    - get(timeout, unit)：超时等待
    - cancel(true/false)：尝试取消
      - true：会向线程发 interrupt
      - false：不 interrupt，只是标记取消
    - isDone()/isCancelled()
- 线程生命周期与状态
  - Java Thread.State
    - NEW：未 start
    - RUNNABLE：可运行（包括运行中+就绪）
    - BLOCKED：等待获取 monitor 锁（synchronized 竞争）
    - WAITING：无限期等待（Object.wait()/Thread.join()/LockSupport.park()）
    - TIME_WAITED：限时等待（sleep()/wait(timeout)/join(timeout)/parkNanos）
    - TERMINATED：结束
  - BLOCKED 和 WAITING 的区别
    - BLOCKED：卡在 synchronized，等锁
    - WAITING：已经拿到锁，主动等待某个条件
  - 线程切换成本
    - 上下文切换：保存恢复寄存器、栈、调度
    - CPU cache 命中下降
    - 线程越多，竞争越激烈，吞吐反而下降
- 中断机制：interrupt 不是杀进程
  - 三个 API 的语义
    - thread.interrupt()：给线程设置中断标志位
    - thread.isInterrupted()：读取中断标志位（不清除）
    - Thread.interrupted()：读取当前线程的中断标志位，并且清除
  - 那些操作对中断敏感
    - 会抛 InterruptedException （清除中断标志）
      - Object.wait()
      - Thread.sleep()
      - Thread.join()
      - BlockingQueue.put/take 等可中断阻塞
    - Lock 的可中断
      - lockInterruptibly()：阻塞等锁时可响应 interrupt
      - lock()：等锁期间不相应 interrupt
  - 优雅停线程
    - 循环里检查中断标志
    - 捕获 InterruptedException 后要么退出，要么重新设置中断标志位再退出/上抛
- 线程安全方法论
  - 不变性
    - 对象状态创建后不再改变
    - 示例： String、Interger
    - 业务做法：配置对象、DTO 用不可变 + 构造完成后安全发布
    - 优点：天然线程安全、无锁高性能
    - 缺点：需要复制，内存开销上升
  - 线程封闭
    - 数据只在一个线程访问
    - 典型：方法栈内局部变量、线程私有变量
    - 示例：每个线程一个 SimpleDateFormat
  - 同步互斥
    - 通过临界区序列化访问共享状态
  - 无锁/低锁
    - 原子类/CAS、分段化
- Synchronized
  - Synchronized 锁的是什么
    - synchronized(obj)：锁 obj 的 monitor
    - synchronized 实例方法：锁 this
    - static synchronized: 锁 Class 对象（xxx.class）
    - 锁的是对象的 monitor，不是代码块本身
  - synchornized 三大语义
    - 互斥：同一时刻只有一个线程进入临界区
    - 可见性：释放锁前的写，对之后获取同一锁的线程可见
    - 可重入：同一线程可重复获得同一把锁
  - 锁升级
    - 目标：在无竞争/低竞争时，让 synchronzied 尽可能便宜；在竞争激烈时保证正确性与吞吐。
    - 策略
      - 无竞争：尽量不做原子指令/不进内核
      - 少量竞争：用 CAS + 自旋解决（避免线程阻塞/唤醒成本）
      - 激烈竞争：进入 monitor，阻塞/唤醒
    - 对象头与 Mark Word：锁状态存在哪里
      - 每个 Java 对象在 HotSpot 里都有对象头，核心是 Mark Word，用于存：
        哈希码
        GC 分代/标记信息
        锁相关信息（锁标志位、线程 ID、指针等）
      - synchronized 不单独存一个锁对象结构，优先把锁状态编码在对象头里；必要时才膨胀到 monitor(重量级)。
    - 四种主要锁形态
      - 无锁
        对象头处于可锁定但未加锁状态
        第一次进入 synchronized，会走向偏向/轻量的获取逻辑
      - 偏向锁
        适用场景：几乎总是同一个线程反复进入同一把锁
        核心思想：预期每次都 CAS/自旋，不如直接偏向某个线程
        MarkWord 记录偏向的线程 id
        同一线程再次进入，只需要快速检查是不是我，几乎零成本
        偏向锁的获取：
        第一次进入：尝试把对象头偏向当前线程（轻量 CAS 一次）
        再次进入：只做线程 ID 校验
        偏向锁的撤销
        另一个线程也来竞争这把锁
        偏向线程已经结束，且有其他线程来加锁
        JVM 需要批量撤销/重偏向
      - 轻量级锁
        适用场景：有短暂竞争，但竞争不激烈；临界区很短
        核心机制
        线程在栈上创建一个 Lock Record（锁记录）
        把对象头的 Mark Word 复制到 Lock Record（保存旧值）
        用 CAS 尝试把对象头替换为指向 Lock Record 的指针（同时设置轻量锁标志）
        CAS 成功：拿到轻量锁
        CAS 失败：说明有竞争 -> 可能自旋等待 -> 若仍失败/竞争升高 -> 膨胀为重量级锁
      - 重量级锁
        使用场景：竞争激烈，自旋会浪费 CPU，或者线程阻塞更划算
        核心机制
        对象关联一个 ObjectMonitor
        竞争失败的线程进入 EntryList/WaitSet（不同状态的队列）
        由 OS 互斥/park-unpark 等机制进行阻塞与唤醒
        特点
        成本高：涉及线程挂起/唤醒、上下文切换
        高竞争下更稳定：避免大量线程空转自旋把 CPU 烧穿
- wait/notify：线程协作的基础
  - wait/notify 使用规则
    - 必须在 synchronized 内调用，否则抛 IllegalMonitorStateException
    - wait() 会
      - 释放当前 monitor
      - 把线程放入该 monitor 的等待队列
      - 被唤醒后需要重新竞争锁
    - 永远用 while 检查条件，不用 if
      - 防止虚假唤醒
      - 防止被唤醒时条件已被其他线程改变
  - notify vs notifyAll
    - notify(): 随机唤醒一个等待线程
    - notifyAll(): 唤醒全部等待线程，让它们竞争并再次检查条件
    - 多数条件 prefer notifyAll，除非非常确定只存在一种等待条件且不会误唤醒
  - wait/notify vs sleep
    - sleep()：不释放锁，属于 Thread 方法，主要用于延时
    - wait()：释放锁，属于 Object 方法；用于条件等待
- Condition 与 LockSupport：更现代的协作手段
  - Condition 相对 wait/notify 的优势
    - 可拥有多个条件队列
    - API 更清晰 await/signal/singalAll
    - 与 ReentrantLock 组合可实现更复杂的并发控制
  - LockSupport
    - park() 阻塞当前线程
    - unpark(thread)：给某个线程发许可，让它从 park 返回
    - unpark() 可以先于 park 发生，比 wait/notify 更灵活
- 可中断的生产者-消费者
- Condition 版本

JUC 核心与 AQS

JUC 核心与 AQS
- CAS 与原子类
  - CAS 是什么
    - CAS 本质是一个 CPU 原子指令
    - 比较内存位置的值是否等于 expected
    - 是则写入 update
    - 返回成功/失败
  - CAS 解决了什么
    - 解决复合更新在并发下的原子性
    - 避免锁的阻塞/唤醒，吞吐通常更高
  - CAS 的代价
    - 自旋重试：竞争大时空转，CPU 飙高
    - 可能导致某些线程长期失败
  - AtomicInteger/AtomicLong 的工作方式
    - AtomicInteger.incrementAndGet()，本质是
      - 循环：读旧值 -> 计算新值 -> CAS 尝试更新 -> 失败重试
    - 原子类=CAS 自旋 + volatile 语义，失败重试直到成功
  - ABA 问题
    - 问题描述
      - 线程 T1 看到值为 A，准备 CAS 成 B；期间 T2 把 A 改成 C 又改为 A。
      - T1 CAS 会成功，它不知道中间发生过变化
    - ABA 什么时候有害
      - 关心的是值有没与变过，而不是当前值是不是 A
    - 解决方案
      - 版本号：AtomicStampedReference（值+stamp）
      - 也有 AtomicMarkableReference（值+boolean 标记）
    - LongAddr 为什么比 AtomicLong 快
      - AtomicLong：所有线程竞争同一个 value，CAS 冲突高
      - LongAdder：把热点拆分成多个 Cell，线程尽量更新自己的 Cell，最后 sum 时聚合
- AQS：JUC 的核心骨架
  - AQS 最重要的三件东西
    - state (volatile int)：同步状态
    - CLH 变体 FIFO 队列：等待线程排队
    - acquire/release 模板方法：统一的获取/释放流程
    - AQS 用 state 表示资源，用队列管理竞争失败的线程，用 acquire/release 模板屏蔽排队、阻塞与唤醒细节，同步器只要实现 tryAquire/tryRelease
  - AQS 的两种模式
    - 独占：一次只允许一个线程获取
      - ReentrantLock、ReentrantReadWriteLock 的写锁
    - 共享：运行多个线程同时获取
      - Semaphore、CountDownLatch、读锁
  - acquire/release
    - acquire
      - tryAcquire() 尝试直接获取资源
      - 失败：把当前线程包装成 Node 入队
      - 自旋检查是否轮到自己（前驱是 head 且再 tryAquire）
      - 若仍然失败，park 阻塞
      - 被唤醒后继续循环
      - 要点
        不是一直自旋：会 park
        唤醒不是广播，通常唤醒一个合适的后继节点，避免惊群
    - release
      - tryRelease() 修改 state（释放资源）
      - 如果释放后资源可用，唤醒队列中的后继节点
  - 为什么 AQS 用队列
    - 避免一堆线程同时自旋抢锁造成 CPU 爆炸
    - FIFO 队列提供基本公平性基础
    - park/unpark 做阻塞唤醒，减少上下文切换次数（相对 monitor 更加可控）
- ReentrantLock
  - ReentrantLock 相比 synchronized 的能力点
    - 可中断：lockInterruptibly()
    - 可超时：tryLock(timeout)
    - 可选择公平/非公平
    - 多 Condition（多个等待队列）
    - 缺点：必须手动释放锁，代码更啰嗦
  - 公平 vs 非公平
    - 公平锁：大致按照队列先来先服务，吞吐更低
    - 非公平锁：允许插队，先 CAS 抢一把，吞吐更高，可能造成某些线程等待更久
  - 可中断锁为什么重要
    - 线程在等锁时被取消/超时，希望立即退出而不是继续卡死
    - lock()：等待锁期间不响应 interrupt
    - lockInterruptibly()：能响应 interrupt，抛 interruptedException
- Condition：两个队列（同步队列+条件队列）
  - Condition 的语义
    - await()：释放锁+当前线程进入条件队列+park
    - signal()：把条件队列头部线程转移到同步队列
    - 线程真正执行
      - 被 signal 转移到同步队列
      - 重新竞争锁成功 (acquire)
      - await 返回继续跑
  - 常见同步工具类
    - CountDownLatch（一次性门闩）
      - state = count
      - await()：共享获取，直到 count == 0 全部放行
      - countDown()：释放，count–，到 0 唤醒所有等待者
      - 适用场景
        主线程等待多个子任务完成
        服务启动前等待依赖就绪
      - count 到 0 后不能重置
    - Semaphore（信号量：限流/资源池）
      - state = permits
      - acquire()：permits–，不够则排队阻塞
      - release()：permits++，唤醒等待者
      - 适用场景
        限制并发数
        连接池/令牌桶
    - CyclicBarrier（客服用栅栏，非 AQS 典型）
      - 让一组线程在栅栏处互相等待，达到数量后一起继续
      - 可复用
      - 用于并行计算分段后汇总

线程池与并发工程实战

线程池与并发工程实战
- 不用线程池的问题
  - 线程创建/销毁成本高（栈、TLAB、调度）
  - 不可控：并发暴涨会把机器压垮
  - 缺乏治理能力：无法统一命名，监控、拒绝、限流、隔离
- ThreadPoolExecutor
  - 七大参数
    - corePoolSize（核心线程数）
      - 默认不会受
      - 任务来时优先创建核心线程直到达到 core
    - maximumPoolSize（最大线程数）
      - 队列慢后，才会创建非核心线程，直到 max
      - 超过 max 再来任务 -> 触发拒绝策略
    - keepAliveTime（空闲存活时间）
      - 非核心线程空闲超时会回收
      - 若允许核心线程超时，则核心线程也会回收
    - workQueue （任务队列）
      - 决定任务是排队还是扩线程的关键
    - threadFactory（线程工厂）
      - 线程命名，daemon、优先级、UncaughtExceptionHandler
      - 工程强制：必须设置可读名称
    - handler（拒绝策略）
      - 线程数到 max 且队列满->触发拒绝
    - unit（时间单位）
  - 线程池执行流程
    - 若 workerCount < corePoolSize
      - 创建核心线程执行 task
    - 否则尝试入队 workQueue.offer(task)
      - 入队成功：等待线程从队列取任务
    - 入队失败，且 workerCount < maximumPoolSize
      - 创建非核心线程执行 task
    - 否则，拒绝策略 handler.rejectExecution(task, executor)
  - workQueue 选型
    - LinkedBlockingQueue(无界/大容量队列)
      - 特点
        极容易入队成功，导致线程数通常停在 core，不会扩到 max
        如果队列无界：任务堆积 -> 内存膨胀/延迟飙升，最终 OOM 或雪崩
      - 适用：任务流量可控，任务执行稳定，且能接受排队延迟
    - ArrayBlockingQueue(有界队列)
      - 特点
        队列有界，能把系统压力显式化
        延迟更可控，便于做背压与降级
      - 线上服务强烈推荐：有界队列+明确拒绝策略
    - SynchronousQueue(不存任务，直接提交)
      - 特点
        没容量，offer 必须被 worker 立即 take 才算成功
        适合快速扩线程，直到 max，然后拒绝
        newCachedThreadPool 就是它，风险是线程数可能飙升
- 拒绝策略
  - 四种内置策略
    - AbortPolicy（默认）：抛 RejectedExecutionException
      - 适合你希望调用方显式失败，触发降级/重试逻辑
    - CallerRunsPolicy：调用方自己执行任务
      - 适合给上游施加背压（请求线程被拖慢，QPS 自然下降）
    - DiscardPolicy：静默丢弃
      - 适合：允许丢数据的场景（采样、非关键日志）
    - DiscardOldestPolicy：丢弃队列最老任务，再尝试入队
      - 适合：追求新任务更重要的场景
  - 工程化拒绝策略（建议自定义 handler）
    - 记录指标（reject count、queue size、active count）
    - 打点日志
    - 触发降级
    - 投递到补偿通道
- Executors 工厂的问题
  - newFixedThreadPool
    - 默认用无界 LinkedBlockingQueue：堆积导致 OOM/延迟失控
  - newCachedThreadPool
    - 默认 SynchronousQueue + max=IntegerMAX_VALUE：线程数可以无限膨胀
  - newSingleThreadExecutor
    - 无界队列，同样堆积危险
  - 生产环境建议显式 new ThreadPoolExecutor：有界队列、合理 max、明确拒绝策略、线程命名与监控
- 线程数怎么配置
  - CPU 密集型
    - 线程数 = CPU 核心数
    - 目标：减少上下文切换
  - IO 密集型
    - 线程数 = 核心数 * (1+等待时间/计算时间)
    - 工程上推荐压测（不同线程数）-> 看吞吐/延迟/CPU/上下文切换->找拐点
- CompletableFuture
  - 解决的问题
    - 传统 Future 的痛点
      - 只能 get() 阻塞拿结果，组合多个异步任务很痛苦
      - 异常处理分散，超时与取消不优雅
      - 任务依赖关系需要手写线程/回调
    - CompletableFuture 的定位
      - 提供声明式的异步流水线
      - 支持任务依赖、并行、聚合、异常处理、完成回调
  - 核心心智模型
    - Stage（阶段）
      - 每个 thenXX 都是在构建一个新阶段
      - 上一个阶段完成后触发下一个阶段
      - 每个阶段都可能
        产出一个值
        抛异常
        被取消
    - Completion（完成态）
      - Completable 可能以三种方式结束
        正常完成（有结果）
        异常完成（exceptionally completed）
        被取消（cancelled）
    - Executor
      - 必须管理在哪个线程执行阶段
  - 线程池与执行线程
    - 默认线程池
      - supplyAsync/runAsync：不传 executor 时，默认走 ForkJoinPool.commonPool
      - commonPool 是全局共享池：你的业务、第三方库、框架都可能在用
      - 工程风险
        隔离性差
        阻塞任务不友好
        排障难
    - thenApply vs thenApplyAsync
      - thenApply(fn)：默认在完成上游阶段的线程里执行
      - thenApplyAsync(fn)：异步执行
        不传 executor：用 commonPool
        传 executor：用指定的线程池
  - 常用 API 分组
    - 创建与启动
      - completableFuture(value)：已完成（同步值包装）
      - runAsync(Runnable, executor?)：无返回值任务
      - supplyAsync(Supplier, executor?)：有返回值任务
      - new CompletableFuture<>() + complete/completeExceptionally：手动控制完成
    - 转换 map 与消费 consume
      - thenApply(fn): T->U
      - thenAccept(consume): 消费结果（无返回）
      - thenRun(runnable)：不关心结果，只做后续动作
    - 串联
      - thenCompose(fn): T->CompletableFuture，扁平化
        用于上一个异步结果决定下一个异步请求
    - 并行组合
      thenCombine(other, (a,b)->c)：两个都完成后合并
      allOf(f1,f2,…)：全部完成
      anyOf(f1,f2,…)：任意一个完成
      applyToEither(other, fn)：谁先完成用谁的结果
      acceptEither：谁先完成就消费
    - 异常处理
      exceptionally(ex -> fallback)：异常时给兜底值
      handle((res, ex) -> …)：无论成功失败都处理
      whenComplete((res, ex) -> …)：做副作用，不改变结果
    - 最佳实践
      主链用 handler 或 exceptionally 做兜底
      whenComplete 做日志与 metrics

并发容器、阻塞队列、并发设计

并发容器、阻塞队列、并发设计
- 并发容器解决的问题
  - 线程安全访问：多线程读写不会破坏结构、不丢数据
  - 性能：比 Collections.synchronizedXxx/Hashtable 更高吞吐
  - 语义更强：有些容器提供阻塞、延时、优先级等能力
- 选型
  - Map -> ConcurrentHashMap
  - List -> 读多血少用 CopyOnWriteArrayList
  - Queue -> 无界非阻塞 ConcurrentLinkedQueue，有界阻塞用 ArrayBlockingQueue/LinkedBlockingQueue
  - Set -> ConcurrentHashMap.newKeySet()/CopyOnWriteArraySet
  - Deque -> ConcurrentLinkedDeque/LinkedBlockingDeque
- ConcurrentHashMap
  - CHM 为什么比 Hashtable 快
    - Hashtable：方法级 sychornized，所有操作串行
    - CHM：更细粒度控制
      大部分读操作无锁
      写操作只锁定桶/节点，并结合 CAS
  - CHM 的核心结构
    - 底层是 Node<K,V>[] table（桶数组）
    - 桶内结构：链表(node)或红黑树
    - 当链表过长且 table 足够大时，会树化降级查找复杂度
  - put 的并发控制逻辑
    - table 未初始化：先初始化
    - 根据 hash 找桶下标 i
    - 如果桶为空：尝试 CAS 放入新 Node
    - 若桶非空
      若桶是迁移中：帮助扩容
      否则对桶头做 synchronzied 局部锁，在桶内插入/更新
    - 插入后可能触发 size 技术更新与扩容检查
- CopyOnWriteArrayList(COW)：读多写少
  - 核心机制
    - 写操作会
      加锁
      复制底层数组
      在新数组上修改
      用引用替换发布新数组
    - 读操作直接读数组快照，无损
  - 适用与不适用
    - 适用
      读远多于写
    - 不适用
      写频繁
      数组很大
- 并发队列：非阻塞 vs 阻塞
  - ConcurrentLinkedQueue(CLQ)：非阻塞队列
    - 基于 CAS 的链表队列
    - 适合：高并发无界、低延迟、允许忙等/自旋语义的场景
    - 特点
      offer/poll 非阻塞
      size() 可能是线性复杂度
  - BlockingQueue：核心语义
    - BlockingQueue 的关键是两种阻塞语义
      当队列为空：take() 阻塞直到有元素
      当队列满：put() 阻塞直到有空间
      offer/poll 返回特殊值
- 三大常用阻塞队列
  - ArrayBlockingQueue(ABQ)-有界数组队列
    - 底层数组环形缓冲区
    - 一般用一把锁 + 两个 condition
    - 特点
      有界：最重要的工程优势
      内存局部性好
      吞吐稳定，适合线程池工作队列
    - 生成服务最常用的稳健默认
  - LinkedBlockingQueue(LBQ)-链表队列(可无界/大容量)
    - 链表节点存储，内存分配频繁（节点对象）
    - 常见实现会用两把锁来提高并行度
    - 风险：堆积导致 OOM 与延迟失控
  - SynchronousQueue(SQ)-不存储元素的移交队列
    - 容量为 0，put 必须等待 take 直接接手
    - 特点：几乎不用排队，延迟低
- DelayQueue/PriorityBlockingQueue：定时与优先级
  - DelayQueue 延时队列
    - 元素实现 Delayed，按到期时间排序
    - take() 会阻塞直到最近到期元素到期
    - 适用：超时重试、订单超时关闭、缓存过期处理（小规模）
    - 工程上：大量定时任务用时间论/调度框架
  - PriorityBlockingQueue(优先级队列)
    - 无界优先级堆
    - 高优先级先出队