集合框架与流处理

• unmodifiableMap 的不可变视图
• synchronizedMap 的同步包装
• 两者差异与适用场景

unmodifiableMap 返回一个只读视图，任何修改操作抛 UnsupportedOperationException，用于暴露不可变数据、防止内部状态被修改，适合作为对外只读接口（如配置、常量）。synchronizedMap 用互斥锁包裹所有方法，保证线程安全，但每个方法调用都加锁、粒度粗、并发度低，且复合操作（如迭代时）仍需要外部同步。工程价值：unmodifiableMap 强调"不变性"，synchronizedMap 强调"线程安全"，二者适用场景不同，实践中现代并发场景多优先用 ConcurrentHashMap 替代 synchronizedMap。

unmodifiableMap 管"不可变"，synchronizedMap 管"线程安全"，价值取向不同。unmodifiableMap 利于安全发布与防御性编程，synchronizedMap 因粗粒度锁性能差，通常被并发容器替代。

• 锁粒度差异
• 并发度与性能
• 现代选择

Hashtable 与 synchronizedMap 用单一全局锁（或包装器锁）保护整个映射，任何读写都会串行化，并发度低、性能差。ConcurrentHashMap 在 JDK8 用数组 + 链表/红黑树，通过 CAS（无锁）与细粒度锁（bin 头节点同步）实现高并发，读操作无锁、写操作只锁冲突的桶，并发度与性能显著更高。JDK8 的 ConcurrentHashMap 摒弃了分段锁，采用更细的粒度与 CAS。现代并发场景应优先 ConcurrentHashMap，Hashtable/synchronizedMap 已基本被淘汰。

差异根源是"全局锁 vs 细粒度锁/CAS"。ConcurrentHashMap 用无锁读 + 按桶锁写，把并发度提升到桶级别，故性能远优于全局锁的 Hashtable/synchronizedMap。

• 并行遍历 API
• 顺序保证的边界
• 遍历期间修改

ConcurrentHashMap 提供 forEachKey/forEachValue/forEachEntry 等批量操作，可指定并行度（threshold）在 ForkJoinPool 上并行执行。这些遍历的"weakly consistent"（弱一致）语义：遍历期间发生的修改可能反映也可能不反映，不保证反映所有元素，也不保证顺序。顺序保证上，并行遍历无确定性顺序，即使并行度为 1 也不能保证全局一致顺序。遍历期间的并发修改不会导致 ConcurrentModificationException，但结果是不确定的。因此这些遍历适合"统计、聚合、foreach 副作用"等不依赖顺序的场景，不适合需要精确顺序或快照一致的操作。

弱一致语义是"允许并发修改、不保证顺序与一致性"。并行遍历适合无顺序要求的聚合，边界是"不能依赖顺序与一致性快照"。

• CAS 原子操作
• putIfAbsent 语义
• 条件 remove/replace

JDK8 的 ConcurrentHashMap 提供原子性的条件操作：putIfAbsent(key, value) 仅当 key 不存在时放入，返回旧值（无则 null）；remove(key, value) 仅当当前值与指定 value 相等时移除，返回是否成功；replace(key, oldValue, newValue) 仅当当前值等于 oldValue 时替换为 newValue，返回是否成功。这些操作在并发下是原子的（基于 CAS 或桶级锁），避免了"先读后写"的竞态，是实现原子更新、缓存加锁、去重等逻辑的基础。

这些操作把"检查-修改"封装为原子动作，避免并发下的竞态。其底层是 CAS 或桶同步，保证单值上的原子性。多值复合操作仍需外部同步。

• transform/reduce 批量并行
• ForkJoinPool.commonPool
• 并行度与协作

ConcurrentHashMap 的 reduce、transform、search 等批量方法支持并行：当元素数超过 threshold（并行阈值）时，任务提交到 ForkJoinPool.commonPool 并行执行，多个线程分片处理 map 的桶并归并结果。ForkJoinPool.commonPool 是全局共享的公共池，并行度默认等于 CPU 核数 - 1。协作体现在：批量操作自动切分桶、并行归约，降低单个线程的扫描开销。但 commonPool 是共享的，若大量任务同时提交会争用公共线程，且阻塞操作会占用公共线程影响其他任务，应避免在 commonPool 中执行阻塞性操作。

并行批量操作利用 commonPool 分片并行归约，提升吞吐。但 commonPool 是共享有限资源，需注意并行度与阻塞操作，避免公共池被占满。

• JDK7 头插法死循环
• JDK8 尾插法
• 仍不并发安全的边界

JDK7 的 HashMap 在扩容 rehash 时采用头插法转移链表，并发下多个线程同时扩容会导致链表成环，get 时死循环。JDK8 改用尾插法，配合红黑树化，避免了扩容时链表成环的死循环问题。但 JDK8 的 HashMap 仍不保证并发安全：并发 put 时可能数据丢失、覆盖（如两个线程同时写同一桶，一个覆盖另一个），size 计数不一致，put 时可能触发非原子操作导致异常。因此 HashMap 只用于单线程，并发场景必须用 ConcurrentHashMap。

尾插法消除"扩容成环"，但并发写入的"覆盖/丢失"问题依然存在。死循环是 JDK7 的特定缺陷，JDK8 修复了它，但整体并发安全并未保证。

• 各方法语义
• compute/merge 的原子内部逻辑
• 使用场景

put 无条件放入；putIfAbsent 仅当 key 不存在才放入（用于初始化默认值）；compute 用函数基于 key 和旧值计算新值（可不存在 key 时初始化）；merge 用函数合并旧值与新值，适合"累加、计数、合并"（如 map.merge(key, 1, Integer::sum)）。工程价值：putIfAbsent 避免覆盖已有值；compute/merge 把"读-算-写"封装为原子（相对单线程）操作，避免重复读写，代码简洁。注意这些操作在单线程下安全，并发仍需 ConcurrentHashMap。

这些方法把常见"检查-更新"模式封装为简洁 API。compute/merge 用函数式更新避免手写 read-modify-write，是计数与聚合的利器。

• 结构化并发（Structured Concurrency）
• CompletableFuture 链式组合
• 错误处理与资源管理

CompletableFuture 用链式回调组合异步任务（thenApply、thenCombine、allOf 等），灵活但存在"火与遗忘"问题：任务在无限线程池上运行，子任务失败不易传播、取消难以级联、线程不被管理导致泄漏。结构化并发（JEP 453，StructuredTaskScope）把子任务绑定到一个结构化作用域，所有子任务在作用域结束前完成，统一聚合结果、传播取消与失败，保证无泄漏、生命周期清晰。取舍：CompletableFuture 灵活适合非结构化组合，但资源管理弱；结构化并发适合"并行化处理并在同一作用域汇总"的场景，可读性与资源管理更好。二者可结合：结构化并发负责并行任务，CompletableFuture 负责结果组合。

结构化并发强调"任务生命周期可控"，CompletableFuture 强调"灵活组合"。前者解决线程泄漏与取消传播，后者解决复杂链式组合。取舍看是否需严格生命周期管理。

• 结构化作用域
• 线程泄漏预防
• 取消传播

结构化并发通过 StructuredTaskScope 把子任务限制在代码结构化的作用域内：作用域内启动的所有子任务必须在作用域结束前完成（join），作用域关闭时若子任务未完成会被强制取消并等待回收，从而保证"不泄漏任何线程"。取消传播：父任务被取消或作用域关闭时，所有未完成子任务被级联取消，取消沿结构化作用域传播，无需手动管理。这解决了 CompletableFuture 等非结构化并发中"任务在无限池上运行、取消不级联"的泄漏与失控问题。

结构化并发用"作用域约束 + 作用域结束强制清理"杜绝线程泄漏，用"作用域关闭级联取消"实现取消传播。这是它与非结构化并发最本质的区别。

• 底层结构
• 随机访问复杂度
• 插入删除复杂度

ArrayList 基于连续数组，随机访问 O(1)（按下标直接定位），尾插 O(1) 均摊，中间插入/删除需移动元素 O(n)，且扩容有拷贝开销。LinkedList 基于双向链表，随机访问 O(n)（需遍历），头尾插入删除 O(1)，中间插入需定位 O(n)。工程上，绝大多数场景（随机访问、遍历、尾插）ArrayList 更优，内存更紧凑、缓存友好；LinkedList 的"中间插入 O(1)"只在持有节点引用时成立，实际常常因定位而退化，且内存开销大（每个节点有前后指针）。因此实践中 LinkedList 很少是最优选择。

差异来源是"数组 vs 链表"的结构。ArrayList 随机访问快、紧凑，LinkedList 头尾操作快但访问慢、内存大。工程上 ArrayList 通用性更强。

• 扩容策略（1.5 倍）
• Arrays.copyOf 拷贝
• 均摊复杂度

ArrayList 在容量不足时扩容：新容量约为旧容量的 1.5 倍（JDK8 中 oldCapacity + (oldCapacity >> 1)），通过 Arrays.copyOf 把旧数组复制到新数组。扩容是 O(n) 拷贝，但因扩容次数对数级增长，均摊后每次 add 仍是 O(1)。1.5 倍（而非 2 倍）是"扩容次数与内存浪费"的折中：比 2 倍少浪费内存、比 1.5 倍以下少扩容次数。工程价值：预分配容量（new ArrayList<>(n)）可避免频繁扩容拷贝，是性能优化点。

扩容本质是"用拷贝换空间"，1.5 倍均衡扩容次数与内存。预分配容量消除扩容拷贝，是常见性能优化。均摊复杂度保证 add 稳定 O(1)。

• volatile 读
• Unsafe 的 getObjectVolatile
• 节点数组与桶的可见性

JDK8 的 ConcurrentHashMap 的 get 不加锁，可见性通过 volatile 语义保证：成员变量（table 数组、sizeCtl 等）用 volatile 修饰，桶的链表头节点通过 Unsafe.getObjectVolatile 读取。写入时用 CAS 或 volatile 写保证先行关系。这样 get 能读到最新已发布的节点，且无需加锁。当 key 不在首节点时可能遍历链表，链表节点在 put 时通过 volatile 写/next 发布，保证可见性。扩容时 get 通过 ForwardingNode 感知并到新表读取，保证一致性。

get 无锁的可见性靠"volatile 读 + 写发布"。volatile 保证读线程看到写线程已发布的最新状态，配合 CAS 的原子写，实现无锁读。

• 多线程协助扩容
• sizeCtl 含义（负数标记）
• transfer 的桶迁移

JDK8 的 ConcurrentHashMap 扩容时，多个线程可协助迁移桶（transfer）：每个线程领取若干桶（通过 stride 分片），用 ForwardingNode（转发节点）标记已迁移的桶，其他线程遇 ForwardingNode 会协助或据其到新表操作。sizeCtl 是状态控制变量：负数时表示扩容进行中（-1 表示初始化，-N 表示有 N-1 个线程在扩容），正数表示阈值或初始容量。扩容的启动、线程协助、结束都由 sizeCtl 状态机协调，保证多个线程安全地共同完成迁移。

多线程协助扩容的核心是"分桶迁移 + ForwardingNode 标记 + sizeCtl 状态机"。sizeCtl 负数标记扩容状态，协调线程加入与退出，大幅提升扩容吞吐。

• 初始容量与负载因子
• 固定 0.75
• 调优策略

ConcurrentHashMap 的负载因子固定为 0.75，不可配置（与 HashMap 不同）。初始容量可通过构造参数（initialCapacity）指定，内部会按"容量 × 负载因子 ≥ 期望元素数"调整到合适的 2 的幂。调优策略：已知元素规模时，通过 initialCapacity 预留足够容量，避免扩容带来的额外开销；但并发场景中容量过大反而增加内存与桶数，需权衡。load factor 0.75 是空间与性能的平衡点，固定值简化了实现。合理预估容量是主要的调优手段。

负载因子固定 0.75 是"空间 vs 冲突"的折中。调优重点是 initialCapacity 按预估元素数预留，避免扩容与过度配置。

• size() 与 mappingCount() 语义
• 分段计数
• 弱一致统计

ConcurrentHashMap 的 size()/mappingCount() 返回元素数量的近似值，不保证实时精确（弱一致），因为并发修改下计数是估算。JDK8 用 LongAdder 风格的分段计数（CounterCell 数组）在并发下分散计数，减少竞争，返回时累加各段。mappingCount() 返回 long 类型，用于超过 int 范围的计数。这些计数的语义是"近似且单调"，适合作为统计、监控等不要求精确的场景。注意 size() 返回 int，可能溢出。

分段计数（CounterCell）用分散计数减少竞争，与 LongAdder 同源。返回值是弱一致近似值，适合统计而非精确判断。

• 树化条件（链表长度 ≥ 8 且容量 ≥ 64）
• 红黑树查找 O(log n)
• 并发查找优势

ConcurrentHashMap 在链表长度超过阈值（TREEIFY_THRESHOLD = 8）且容量达到 64 时，把链表转为红黑树（treeifyBin）。树化后查找从 O(n) 降到 O(log n)，在哈希冲突严重时显著提升性能。红黑树的自平衡保证最坏查找为 O(log n)，避免极端哈希分布下链表退化。并发下有树化时通过根节点/桶锁保证并发安全，红黑树在冲突桶上的查找性能更稳定。若桶数 < 64 则先扩容而非树化。

树化条件是"链表 ≥ 8 且容量 ≥ 64"，目的是在哈希冲突严重时用 O(log n) 查找替代 O(n)。红黑树自平衡保证最坏性能，并发下结合桶锁。

• computeIfAbsent 递归陷阱
• IllegalStateException / 死锁
• 规避方法

ConcurrentHashMap.computeIfAbsent 在计算函数内若对同一 map 进行递归更新可能会死锁或抛异常。因为计算函数执行期间持有该 map 的锁或处于"计算中"状态，若在函数内再次对该 map 做同 key 或原 key 的修改，可能触发递归死锁（JDK8 之前）或 IllegalStateException（"Recursive update"）。规避：不要在 computeIfAbsent 的计算函数内修改同一 map；改用 putIfAbsent 后单独初始化，或先 get 再计算再 putIfAbsent；或用独立 map 做计算。这是并发 Map 的经典陷阱。

computeIfAbsent 在计算期间不允许重入修改同一 map，否则死锁/异常。规避核心是"计算函数内不触碰同一 map"，用非重入方式初始化。

• 2 的幂容量与取模优化
• hash() 扰动函数
• 分布均匀性

HashMap 容量固定为 2 的幂，这样计算桶下标用位运算 (n-1) & hash 替代取模（%），性能高且分布由 hash 的低位决定。为提高低位质量，hash() 扰动函数把 hash 的高 16 位与低 16 位异或（h ^ (h >>> 16)），使高位的随机性也参与低位的计算，从而在容量较小（如 16）时也能让高位的特性影响桶分布，减少冲突。2 的幂容量配合扰动函数，让哈希分布更均匀、扩容时映射更简单（旧桶元素要么留在原桶要么 +旧容量）。

2 的幂用位运算优化取模，异或扰动提升低位随机性。二者配合让 key 分布更均匀、减少冲突，是 HashMap 性能的基础。

• JDK7 头插法死循环
• 线程不安全表现
• 并发场景规避

JDK7 的 HashMap 在并发扩容时，多个线程同时 rehash 链表并用头插法插入，可能使链表成环，get 时无线循环。此外，HashMap 并发使用时表现数据丢失与覆盖：两个线程同时 put 到同一桶，后写覆盖先写；size 计数不一致；扩容时并发 put 可能丢失新元素。这些是非同步、非原子操作导致的。规避：单线程使用，并发场景用 ConcurrentHashMap；或外部加锁同步。

死循环是 JDK7 扩容头插法的并发缺陷，数据丢失/覆盖是并发读写非原子导致的。HashMap 本身非线程安全，必须用并发容器或加锁。

• 数组 + 链表 + 红黑树
• 哈希与桶
• 树化与退化

JDK8 的 HashMap 底层是"数组 + 链表 + 红黑树"：数组（Node[]）作为桶，通过 hash 定位桶；桶内发生哈希冲突时用链表存储多个 Node；当链表过长（≥ 8）且容量 ≥ 64 时树化为红黑树，保证查找 O(log n)；当树节点减少（≤ 6）时退化为链表。插入采用尾插法，存储 key-value + hash + next。扩容时按 2 的幂重新映射。这样的结构兼顾了低冲突时的简洁与高冲突时的性能。

"数组 + 链表 + 红黑树"是空间与性能的平衡：数组 O(1) 定位，链表处理冲突，树处理极端冲突。树化/退化阈值避免频繁震荡。

• 扩容 2 倍
• rehash 映射
• 均摊与性能

HashMap 在元素数超过容量 × 负载因子时扩容，新容量为旧容量的 2 倍。扩容后重新计算元素位置（rehash）：因为是 2 倍扩容，元素要么留在原下标，要么移到"原下标 + 旧容量"处，用 (oldCap & hash) 判断，映射简单高效。扩容是 O(n) 但均摊为 O(1)。工程价值：预分配容量减少扩容，扩容时仅移动冲突元素，位运算映射高效。最终使 HashMap 在动态增长下保持 O(1) 均摊性能。

2 倍扩容 + 位运算 rehash 使映射简单、扩容均匀。容量翻倍保证均摊 O(1)，预分配避免频繁扩容。这是 HashMap 支持动态增长的工程基础。

• Resilience4j 组件（熔断、限流、重试、隔离）
• 限流与降级策略
• 配置与下沉

Resilience4j 提供熔断（CircuitBreaker）、限流（RateLimiter）、重试（Retry）、舱壁（Bulkhead）、超时（TimeLimiter）等容错组件。限流降级设计：用 RateLimiter 按 QPS 限制入站流量，超限返回拒绝或降级；用 CircuitBreaker 在故障率超阈值时熔断，快速失败降级到兜底（fallback）；用 Retry 对可重试请求重试；用 Bulkhead 隔离线程池/信号量防止单依赖拖垮全局。降级通常返回缓存、默认值或友好错误。设计上按依赖分层配置，熔断+限流+重试组合，并设置合理的 fallback。

Resilience4j 用"熔断+限流+重试+隔离"多维防护。降级是流量超限或故障时的兜底，保证系统可用性。组合配置需按依赖与SLA设计。

• 有序性（插入序/访问序）
• accessOrder 与 LRU
• 自定义 removeEldestEntry

LinkedHashMap 在 HashMap 基础上维护双向链表，保证遍历顺序：默认插入序（accessOrder=false），构造时设 accessOrder=true 则按访问序（最近访问的排最后）。利用访问序 + 重写 removeEldestEntry 方法，可在插入新元素时判断是否超过容量上限并淘汰最久未访问的（LRU），从而实现一个内存友好的 LRU Cache。这是 LinkedHashMap 最经典的工程价值：以最小代码实现 LRU 缓存（线程安全需外部同步）。

accessOrder=true 把"最近访问"排到末尾，配合 removeEldestEntry 自动淘汰队首，实现精确 LRU。LinkedHashMap 是 LRU 缓存的轻量实现载体。

• 不可变集合
• 拒绝 null 与修改
• 内存与安全

List.of()/Set.of()/Map.of() 创建不可变（immutable）集合：不可增删改、不可含 null、不可变，任何修改抛 UnsupportedOperationException。工程价值：作为常量、配置、安全发布的不可变数据，防止被意外修改；不可变集合可安全共享、线程安全（无需加锁）；实现经过内存优化（紧凑存储）。用于常量列表、参数校验、安全发布等场景。注意其实现是专门的不可变类，与 unmodifiable 包装不同。

不可变集合提供"不可变性"这一安全属性，利于安全发布与线程安全。拒绝 null 与修改，语义明确，是 Java 9+ 的推荐实践。

• 虚拟线程 pinning
• synchronized 与 ReentrantLock
• 取舍

在虚拟线程下，synchronized 在阻塞时（JDK 24 之前）可能发生"钉住"（pinning）：持锁等待时虚拟线程会占用其载体平台线程，不能被释放去执行其他虚拟线程，导致吞吐下降。ReentrantLock 的 lock 在阻塞时不会钉住，虚拟线程可被安全调度。因此虚拟线程场景下优先使用 ReentrantLock（或基于 Lock 的同步，如 JUC 组件）而非 synchronized，避免钉住。JDK 24 的 JEP 491 已修复 synchronized 的钉住问题（通过线程本地的内存屏障），但 ReentrantLock 仍是虚拟线程友好的选择。

虚拟线程钉住是 synchronized 阻塞占用平台线程的问题。ReentrantLock 不钉住，是虚拟线程下的首选。JEP 491 修复 synchronized 钉住。

• parallelStream 与 ForkJoinPool
• 线程安全要求
• 并行收益与风险

parallelStream 把流操作分片到 ForkJoinPool.commonPool 并行执行，适合 CPU 密集、元素量大、可并行化的操作，能提升吞吐。但并行要求：数据源不可变、操作无状态、无副作用，或对共享状态做同步；否则并行会产生竞态与数据错误。另外 commonPool 是共享的，阻塞操作会占满公共线程。工程价值：并行流适用于"纯计算、无共享状态、元素多"的场景，需权衡并行开销与数据量，避免滥用。小数据量或副作用操作应避免并行。

并行流的收益来自多核并行，但前提是"无状态、无副作用、数据量大"。线程安全依赖操作本身的纯净性，否则并行引入竞态。

• WeakHashMap 弱引用
• IdentityHashMap 引用相等
• EnumMap 枚举键

WeakHashMap 以弱引用持有 key，key 无强引用时被 GC 回收，适合缓存（与外部生命周期关联的值，如元数据缓存）。IdentityHashMap 用引用相等（==）而非 equals 比较 key，适合需要按对象身份标识的场景（如序列化对象图、JVM 内部表）。EnumMap 以枚举为 key，用数组实现，性能最高、内存紧凑，适合枚举键的映射（如状态机、配置）。三者针对特定需求提供优化，是通用 Map 的补充。

WeakHashMap 管"无引用自动回收"（缓存），IdentityHashMap 管"按身份标识"（对象图），EnumMap 管"枚举键高效映射"（状态）。选型依据语义与性能需求。

• BlockingQueue 阻塞语义
• 各实现差异
• 适用场景

BlockingQueue 提供阻塞的入队/出队（put/take 阻塞、offer/poll 带超时），是生产者-消费者模式的核心。ArrayBlockingQueue 基于数组、有界、单锁，容量固定，适合有界缓冲；LinkedBlockingQueue 基于链表、可有界/无界、双锁，吞吐高，适合无界或有界队列；PriorityBlockingQueue 基于堆、按优先级出队，阻塞且有序，适合优先级任务。工程价值：线程池用 BlockingQueue 存放任务，不同实现对应不同背压与优先级语义。选型依据是否有界、吞吐、优先级需求。

BlockingQueue 把"阻塞等待"封装为 API，是任务队列与生产者-消费者的基础。数组/链表/堆对应有界性、吞吐、优先级差异。

• DelayQueue 延迟出队
• Delayed 接口
• 定时/延迟任务

DelayQueue 基于优先级队列（堆），元素实现 Delayed 接口（getDelay 返回剩余延迟，compareTo 按到期时间排序），take 时阻塞直到最早到期元素可取出。工程价值：实现"延迟任务队列"，按到期时间排序，到期才出队，用于定时任务、延迟重试、订单超时、分布式延迟任务（配合分布式锁）。相比轮询，DelayQueue 用阻塞等待减少空转，按到期排序高效。注意它是单机内存队列，分布式需结合外部存储。

DelayQueue 用"堆排序 + 阻塞等待"实现按到期时间出队的延迟队列。是内存定时任务的基础，但单机、易丢失，分布式需外部存储。

• EnumSet 枚举位集
• BitSet 位向量
• 位运算效率

EnumSet 用位向量（long 数组）表示枚举集合，针对枚举类型做高度优化的 Set，集合操作（成员、交集、并集）极快且内存紧凑；BitSet 是通用的位向量，用位表示布尔集合，支持位运算（与、或、异或、翻转），适合大量布尔标记的紧凑存储与批量位操作。工程价值：EnumSet 用于枚举集合的高效表示；BitSet 用于权限位、位图、状态标记、大数据量的 set 操作。二者都能以位运算获得极高性能与极小内存。

EnumSet 与 BitSet 都用"位"表示集合，获得 O(1) 成员判断与极低内存。区别是 EnumSet 面向枚举、BitSet 面向通用位向量。

• FFM 安全模型
• Arena 生命周期
• 越界访问防护

FFM API 通过"受限的访问"保证安全：内存通过 MemorySegment 访问，Segment 具有大小、对齐与生命周期（Arena 管理），访问越界（超出 segment 范围）会抛 IndexOutOfBoundsException，防止越界读写。Arena 定义了内存的生命周期，segment 关闭后访问会抛 IllegalStateException。FFM 不替代 JNI 的裸指针，但通过"受限段 + 生命周期 + 越界检查"提供比 JNI 更安全的原生内存访问。访问隔离（restricted）与权限控制由 API 设计保证。

FFM 用"受限的 MemorySegment + Arena 生命周期 + 越界检查"实现安全。越界访问抛异常而非静默破坏，比 JNI 裸指针安全得多。

• JNI 的痛点
• FFM 的动机
• 架构（Linker、SymbolLookup、MethodHandle）

JNI 的痛点：编写 C 头文件、跨语言边界繁琐、错误处理脆弱、性能开销大、开发效率低。FFM API（Project Panama）提供纯 Java 的原生函数调用与内存访问：用 Linker 链接原生库、SymbolLookup 查找符号、MethodHandle 描述函数签名、MemorySegment 管理原生内存，无需手写 C 胶水代码。动机是"用 Java 声明式地调用原生代码，减少样板、提升安全与性能"。架构上 Linker 生成可调用的 MethodHandle，支持标准 C ABI 的函数调用。

FFM 的动机是"简化与安全"，替代 JNI 的手写胶水。架构由 Linker/SymbolLookup/MethodHandle/MemorySegment 构成，声明式调用原生函数。

• 底层与特性
• 顺序语义
• 适用场景

HashSet 基于 HashMap，无序、O(1) 快速查询，用于去重与快速判断存在；LinkedHashSet 基于 LinkedHashMap，保持插入顺序，同时 O(1) 查询，用于"有序去重"；TreeSet 基于红黑树，元素按自然顺序或 Comparator 排序，支持范围查询（headSet/subSet），但 O(log n)。工程价值：去重用 HashSet，需插入序用 LinkedHashSet，需排序与范围查询用 TreeSet。选型依据是否需要顺序与范围操作。

三者底层不同决定语义：HashSet 无序、LinkedHashSet 插入序、TreeSet 排序。按"去重 + 顺序 + 范围"需求选型。

• 6 个月发布节奏
• LTS 版本
• 生产升级策略

JDK 每 6 个月发布新特性版本，每 2 年（奇数版本）发布一个 LTS（长期支持，如 Java 17、21），LTS 提供多年的安全与维护更新。生产升级影响：企业应选择 LTS 版本以获得长期稳定支持，避免频繁升级到非 LTS 特性版本；新特性（如虚拟线程、结构化并发、FFM）先在中间版本成熟，LTS 汇总后企业再升级。升级策略需评估新特性、兼容性、第三方库支持与安全补丁。6 个月节奏加速了特性迭代，但生产应聚焦 LTS 并规划升级窗口。

6 个月节奏"快迭代"，LTS"长稳定"。生产环境选 LTS 避开频繁升级，同时吸收新特性。升级需评估生态兼容与稳定。

• MemoryLayout 定义结构
• VarHandle 访问
• off-heap 内存

FFM 用 MemoryLayout 描述原生内存布局：struct 用 MemoryLayout.structLayout 组合多个成员（如 ValueLayout.JAVA_INT 等），可计算大小、偏移、对齐。访问 off-heap 内存时，用 MemorySegment.allocateNative 分配原生段，再用 MemoryLayout 派生出的 VarHandle（如 layout.varHandle(...)）对该段做读写。VarHandle 提供类型化的原子/普通访问，且带边界检查。这样用声明式布局 + VarHandle 实现安全的 off-heap 内存读写，避免手算偏移。

MemoryLayout 声明布局，VarHandle 提供类型化访问 point。二者配合实现 off-heap 内存的安全读写，是 FFM 内存访问的核心模式。

• MemorySegment 概念
• Arena 生命周期
• 自动/手动释放

MemorySegment 是 FFM 中表示"一段连续内存"的抽象，有大小、对齐、地址、生命周期。Arena 管理段的生命周期：Arena 打开后，其创建的所有 segment 在 Arena 关闭时统一释放。Arena 类型有全局（GlobalArena，永不关闭）、自动（AutomaticArena，GC 回收时释放）、受限（confined，单线程访问）、共享（shared，多线程）。生命周期管理是 FFM 安全的关键：segment 在关闭/越界后访问抛异常，避免悬垂指针与内存泄漏。Arena 把"谁分配、何时释放"结构化。

MemorySegment 是内存抽象，Arena 是生命周期管理器。Arena 关闭统一释放，避免手动管理泄漏。生命周期结构化是 FFM 安全的核心。

• OpenTelemetry 追踪/指标
• Micrometer 指标门面
• 集成与导出

Micrometer 是度量门面（facade），提供统一指标 API（Counter、Timer、Gauge），通过绑定器导出到 Prometheus、JMX 等后端。OpenTelemetry 是观测标准，提供 trace、metric、log 的统一 API 与导出，支持 OTLP 协议。集成方式：Micrometer 可接入 OpenTelemetry（通过 micrometer-registry-otlp 把指标导出到 OTel Collector），或 Micrometer 提供 tracing 支持（micrometer-tracing 桥接 OTel）。实践中 Spring Boot 结合 Micrometer 收集指标、OpenTelemetry 采集追踪与日志，统一导出到 Collector/Backend，实现指标+追踪+日志的关联观测。

Micrometer 管"指标门面"，OpenTelemetry 管"统一观测标准"。二者通过桥接/导出集成，打通指标、追踪、日志，实现标准化的可观测性。

• SequencedCollection 接口
• 有序集合统一访问
• 首尾操作

Sequenced Collections（JEP 431）为 Java 21 引入 SequencedCollection/SequencedSet/SequencedMap 接口，统一了"有序集合"的访问：提供 getFirst/getLast、addFirst/addLast、reversed() 等操作，让 List、Deque、LinkedHashSet、TreeSet 等有序集合有一致的 API。此前这些集合操作 API 分散且不一致。工程价值：统一有序集合的首尾访问与逆序视图，简化代码、提升可读性，减少对具体实现类的依赖。对需要"既有顺序又需首尾操作"的集合场景很有用。

Sequenced Collections 把"有序 + 首尾访问"统一为接口，消除散乱 API。是 Java 21 集合 API 的现代化，提升一致性与可读性。

• ShutdownOnFailure
• ShutdownOnSuccess
• 子任务取消

StructuredTaskScope 支持短路策略：ShutdownOnFailure 在任一子任务失败时关闭作用域并取消其他未完成子任务（快速失败，适合"任一失败即取消"）；ShutdownOnSuccess 在任一子任务成功时关闭作用域并取消其余（适合"任一成功即返回"）。作用域关闭时所有未完成子任务被取消，join 等待全部结束后再聚合结果。这两种策略让"并行执行 + 短路"语义简洁，且子任务取消自动传播，避免不必要的计算与线程浪费。

ShutdownOnFailure/ShutdownOnSuccess 提供"短路"语义，作用域关闭级联取消子任务。这是结构化并发处理"任一失败/成功即结束"的高效模式。

• 模块化单体概念
• 模块边界与依赖
• 应用价值

Spring Modulith 是"模块化单体"的实现：把单体应用按业务域拆分为多个 Java 模块，模块间有明确的公开 API 与依赖边界，模块内部封装，模块间通过公开接口或事件通信。它提供模块边界校验、依赖验证、事件发布（ApplicationEvent）、模块文档生成等能力。价值：兼顾单体部署简单与模块化清晰，可平滑演进为微服务；通过模块边界与依赖规则防止"腐化"，提升可维护性。适合"先单体、模块化、后按需拆分微服务"的演进路径。

Spring Modulith 用"模块化单体"平衡单体与微服务。清晰模块边界 + 事件解耦，提高内聚、降低耦合，并支持平滑演进微服务。

• 中间操作语义
• 惰性求值
• 组合使用

Stream 中间操作：filter 按条件筛选、map 元素映射转换、flatMap 展平嵌套流、distinct 去重、sorted 排序。中间操作是惰性的，只有遇到终端操作才求值，可链式组合。工程价值：用声明式链式调用替代命令式循环，表达清晰、可读性高；惰性求值避免中间集合物化；组合实现"筛选-转换-去重-排序"等复杂数据处理。注意中间操作会引入开销，必要时用短路（limit/findFirst）减少计算。

中间操作镜像了"数据处理管道"的声明式表达。惰性求值 + 链式组合让代码简洁高效，是函数式处理的核心。

• 终端操作语义
• collect 聚合
• reduce 归约

Stream 终端操作触发求值：forEach 遍历副作用、collect 收集到集合（Collectors.toList/toMap/groupingBy）、reduce 归约聚合（如求和、拼接）、count 计数。工程价值：collect 用 Collectors 灵活地转集合、分组、分区、聚合；reduce 实现通用归约；forEach 用于有副作用的遍历。终端操作是管道的结果出口，与惰性中间操作配合，只在需要时求值。合理使用 collect/reduce 可替代大量手写循环。

终端操作是"结果生产"。collect 聚合、reduce 归约、count 计数，配合 Collectors 实现声明式聚合，替代命令式循环。

• Spliterator 概念
• 特征与拆分
• 自定义数据源

Spliterator 是 Stream 遍历与拆分的抽象，提供 tryAdvance（依次遍历）、trySplit（拆分出子 Spliterator 供并行）、estimateSize（预估大小）、characteristics（特征：有序、去重、已排序等）。工程价值：为自定义数据源实现 Spliterator 可接入 Stream 管道，获得惰性遍历与并行能力（parallelStream 通过 trySplit 拆分）。正确声明 characteristics 让优化器做正确优化（如 distinct/sorted 跳过）。自定义 Spliterator 是把"非集合数据源"（如 IO、数据库游标、生成序列）接入 Stream 的关键。

Spliterator 是 Stream 的"数据源适配器"，提供遍历与拆分。自定义 Spliterator 让非集合数据源获得惰性 + 并行能力，是 Stream 扩展点。

• SymbolLookup 查找符号
• MethodHandle 绑定
• 调用原生函数

FFM 中调用原生函数：先由 Linker 获取 nativeLinker，用 SymbolLookup 在库中查找函数符号地址（如 libc 的 strcpy），再用 Linker.downcallHandle 把符号地址与函数签名（MethodType/FunctionDescriptor）绑定为 MethodHandle，最后通过 MethodHandle 以 Java 方式调用。SymbolLookup 负责"找符号"，MethodHandle 负责"call"。参数用 MemorySegment 传递内存、用 MemoryLayout 描述结构。整个流程用 Java 声明式完成，无需 C 胶水。

调用链是"SymbolLookup 找符号 → Linker 绑定 downcallHandle → MethodHandle 调用"。SymbolLookup 管寻址，MethodHandle 管调用，是 FFM 原生调用的核心。

• SynchronousQueue 零缓冲
• 直接交接
• 适用场景

SynchronousQueue 是一个零容量阻塞队列：每个 put 必须等待一个 take，每个 take 必须等待一个 put，直接"交接"元素，不缓冲。工程价值：用于"直接交接"的生产者-消费者模式，不缓存任务，适合需要精确控制缓冲、避免积压的场景。经典应用是 Executors.newCachedThreadPool 的阻塞队列：任务到达时若无空闲线程则直接新建线程执行，不排队。SynchronousQueue 无缓冲，任务交接即达即转，配合动态线程池实现"无积压"的并发执行。

SynchronousQueue 零缓冲实现"直接交接"，无积压。作为 cachedThreadPool 的队列，实现"任务即到即跑"的弹性线程模型。

• TransferQueue 直接交接
• transfer 方法
• 与 BlockingQueue 差异

LinkedTransferQueue 实现 TransferQueue，基于无锁链表，比 BlockingQueue 多一个 transfer(e) 方法：将元素直接交给正在等待的消费者，若无消费者则阻塞等待。它融合了 SynchronousQueue 的直接交接与队列的缓冲能力：有消费者等待时直接交接，无消费者时入队缓冲。工程价值：在生产者-消费者场景中实现"有等待者即交接、无等待者即缓冲"的灵活背压，减少中间缓冲积压，提升吞吐。适合需直接交接又需缓冲的并发队列。

TransferQueue 的 transfer 实现"有消费者即交接、无消费者即缓冲"，比 SynchronousQueue 更灵活。既是队列又能直接交接，适合生产-消费高吞吐。

• closed-world 分析
• reachability metadata
• 反射配置

GraalVM Native Image 采用"closed-world"（闭世界）假设：AOT 编译时静态分析所有可达代码，未达的代码（尤其是动态反射、类加载、代理）不会被包含。这需要 reachability metadata（可达性元数据）声明哪些类/方法/字段需通过反射访问、哪些需保留，否则运行时反射会失败。反射配置通过 reflect-config.json 等元数据文件声明需反射的类、方法、构造器。Spring 等框架用 RuntimeHints 生成这些元数据。closed-world 分析让 Native Image 能提前裁剪、优化，但代价是动态特性需显式声明。

closed-world 让 AOT 裁剪未达代码，但动态反射破坏可达性分析，需 reachability metadata 显式声明。反射配置是 Native Image 与 JVM 动态特性的关键差异。

• 虚拟线程钉住
• synchronized 阻塞
• JEP 491 修复

JDK 24 之前，虚拟线程在 synchronized 块内阻塞时会发生"钉住"（pinning）：虚拟线程的载体平台线程无法被其他虚拟线程复用，导致平台线程被占用、吞吐下降。因为 synchronized 的锁结构在栈上，无法在不释放平台线程的情况下迁移。JEP 491（虚拟线程同步）在 JDK 24 修复：通过更小巧的锁结构（不再绑定栈帧）与线程本地内存屏障，使 synchronized 阻塞不再钉住虚拟线程。修复后虚拟线程中使用 synchronized 与 ReentrantLock 一样可被安全调度。

pinning 是 synchronized 阻塞占用平台线程。JEP 491 用新的锁实现消除钉住，使虚拟线程在 synchronized 下也能被调度，提升虚拟线程的适用性。

• 虚拟线程监控
• JFR 事件
• 线程转储与钉住

排查虚拟线程性能问题可从：用 JFR 记录虚拟线程事件（ThreadSlept、ThreadPark、ThreadStart/End）分析线程生命周期与阻塞；用线程转储（jcmd Thread.dump_to_file）查看虚拟线程的阻塞状态与钉住（pinned）情况；监控虚拟线程数量与载体平台线程利用率；检查是否过度创建虚拟线程（无界）、synchronized 阻塞导致钉住、阻塞调用（如 IO、锁）占用平台线程。核心指标：虚拟线程数、平台线程数、钉住次数、阻塞时长。结合 JFR 与转储定位资源瓶颈。

虚拟线程问题集中在"钉住、过度创建、阻塞风暴"。JFR 事件 + 线程转储 + 平台线程利用率是诊断关键，定位钉住与阻塞点。

• 虚拟线程适用场景
• I/O 密集
• CPU 密集

虚拟线程的优势在 I/O 密集：虚拟线程在阻塞 IO 时释放载体平台线程，让平台线程高效调度大量虚拟线程，突破"平台线程数"瓶颈，吞吐大幅提升。CPU 密集场景虚拟线程无优势——CPU 密集主要是计算，虚拟线程的计算执行与平台线程相同，且过多虚拟线程反而增加调度开销，无法提升核数上限的吞吐。因此虚拟线程适合"大量阻塞 IO"（连接、调用、IO），不适合 CPU 密集（应匹配核数）。选型需识别瓶颈是 IO 还是 CPU。

虚拟线程解决"阻塞 IO 占线程"问题，I/O 密集收益大；CPU 密集受限于核数，虚拟线程无增益。选型看瓶颈在 IO 还是计算。

• MDC 与 ThreadLocal
• 虚拟线程共享平台线程
• 结构化日志替代

传统 MDC 基于 ThreadLocal，但虚拟线程下 ThreadLocal 要谨慎：虚拟线程数量大、ThreadLocal 内存开销大，且虚拟线程复用平台线程时 ThreadLocal 值可能串扰。替代方案：用结构化日志（Structured Logging，如 JSON 日志）把上下文作为字段显式传递（如 trace-id、request-id 作为参数），而非依赖隐式 ThreadLocal；或使用 Scoped Values（JEP 464）以不可变方式在虚拟线程间传递上下文，避免 ThreadLocal 的开销与泄漏。核心是"显式传递上下文"替代"隐式线程上下文"。

虚拟线程下 ThreadLocal 成本高且易串扰。结构化日志把上下文作为显式字段，Scoped Values 提供不可变上下文传递，是 MDC 的替代。

• CRaC 概念
• 快照与恢复
• 资源协调

CRaC（Coordinated Restore at Checkpoint）是 JVM 的"检查点恢复"技术：运行中的 JVM 在某个时刻保存快照（检查点），之后可从快照恢复到内存状态，实现快速启动（秒级）。快照前需协调资源（CRaC 提供 Resource 接口让应用在 checkpoint 前关闭连接、在 restore 后重建），保证可恢复。结合项目（如 Spring Boot）的 CRaC 支持，把已初始化的应用状态固化为快照，恢复时快速就绪。价值是解决"冷启动慢"，但需处理资源（连接、随机数、时钟）的恢复。

CRaC 用"快照整个 JVM 内存 + 资源协调"实现快速恢复。Resource 接口协调 checkpoint/restore 时的资源生命周期，是恢复正确性的关键。

• AOT 编译
• closed-world 分析
• 限制（反射、动态）

GraalVM Native Image 用 AOT（Ahead-Of-Time）编译：把字节码提前编译为原生机器码，而不是运行时 JIT。它做 closed-world 分析，静态确定所有可达代码并裁剪不可达部分，降低体积与启动时间。限制：反射、动态代理、JNI、类加载等动态特性在 AOT 时无法静态确定，需 reachability metadata 声明；不支持或需配置某些动态特性；运行时无 JIT 自我优化，峰值吞吐可能低于热点 JIT。适用于"启动快、体积小、资源受限"的 Serverless/CLI，但需处理动态特性元数据。

AOT 换来"快启动、小体积"，代价是"动态特性需元数据声明、无 JIT 热点优化"。适用场景是启动敏感、资源受限，不适用依赖大量动态特性。

• Native Image 特性
• CRaC 特性
• 选型决策

Native Image（AOT）把应用编译为原生可执行文件，启动毫秒级、体积小，但需处理动态特性元数据、无 JIT 热优化、生态兼容有限。CRaC 保留 JVM 与 JIT，通过快照恢复实现快速启动，能保留 JVM 生态与热优化，但需要协调资源（连接、随机数）且快照占内存。选型：追求极致体积/启动、可接受元数据迁移选 Native Image；想保留 JVM 生态与热优化、只求快启动选 CRaC。二者都解决"冷启动"，但迁移成本与运行模型不同，需按应用动态特性与生态需求决策。

Native Image 是"原生编译"，CRaC 是"JVM 快照"。前者启动快但生态受限，后者保 JVM 但需资源协调。选型看动态特性依赖与生态兼容。

• 启动时间优势
• 峰值吞吐
• JIT vs AOT

Native Image 的启动时间极快（毫秒级），因为免去 JVM 启动与类加载，且 closed-world 裁剪代码。但峰值吞吐通常低于长期运行的 JVM（JIT）：JVM 的 C2 编译器在运行时基于真实 profile 做内联、逃逸分析等激进优化，而 Native Image 无运行时 JIT 优化，峰值吞吐可能较低。权衡：启动敏感、短生命周期、吞吐要求不极致的场景（Serverless、CLI、Job）选 Native Image；长期运行、吞吐敏感、需 JIT 热优化的应用仍用 JVM。需按"启动 vs 峰值"权衡。

Native Image 用"启动快"换"峰值吞吐可能低"。JIT 的运行时 profile 优化是 JVM 峰值优势，AOT 无法获得。权衡取决于生命周期与吞吐需求。

• Scoped Values 概念
• 不可变上下文
• 与 ThreadLocal 对比

Scoped Values（JEP 464）提供不可变、限作用域的上下文值：在结构化作用域内绑定一个值，作用域内所有线程（包括虚拟线程）可读取，作用域结束后不可再访问。相比 ThreadLocal，Scoped Values 不可变、无共享状态、生命周期结构化、适合虚拟线程的高效上下文传递（如 trace-id、租户、请求上下文）。它避免 ThreadLocal 的内存开销与泄漏，且上下文随结构化并发传播。应用：在虚拟线程与结构化并发中传递请求上下文，配合结构化日志实现不可变上下文。

Scoped Values 提供"不可变、结构化作用域"的上下文，是 ThreadLocal 在虚拟线程下的安全替代。适合传递 trace-id 等只读上下文。

• RuntimeHints 概念
• 生成原生元数据
• 反射/资源/代理声明

Spring Boot 的 RuntimeHints API 用于 Native Image 构建时声明运行时需要的元数据：通过 RuntimeHintsRegistrar 或 @RegisterReflectionForBinding 等，声明反射需要访问的类、需加载的资源、动态代理、序列化等。Spring 在构建期扫描这些 hints 并生成 reachability metadata（reflect-config.json 等），供 Native Image 使用。这样框架的动态特性（如 Spring 反射、Jackson 序列化）能在 AOT 下正常工作。RuntimeHints 是 Spring 应用适配 Native Image 的桥梁。

RuntimeHints 在构建期把 Spring 应用的动态需求声明给 Native Image，生成元数据。是 Spring 应用获得快启动同时保持反射/序列化正常的关键。

• 结构化并发理念
• StructuredTaskScope API
• 生命周期与错误

Structured Concurrency（JEP 453）的设计理念是"任务生命周期与代码结构一致"：在结构化作用域内启动的子任务，其生命周期受作用域约束，必须在该作用域结束前完成，否则被取消。API 用 StructuredTaskScope，包含 fork（启动子任务）、join（等待全部完成）、shutdown（关闭作用域）等，配合调用方控制结果与异常。理念是"要么全部完成，要么全部取消"，消除"火与遗忘"、防止线程泄漏。错误处理：join 后聚合结果，异常可传播。ShutdownOnFailure/ShutdownOnSuccess 提供短路策略。

结构化并发让"任务生命周期结构化"，消除泄漏与失控。StructuredTaskScope + fork/join/shutdown 实现"作用域内并行、作用域结束收敛"。

• Testcontainers 概念
• 容器化依赖
• 最佳实践

Testcontainers 用 Docker 容器为集成测试提供真实依赖（数据库、消息队列、Redis 等），保证测试环境与生产一致。最佳实践：使用 @Container/@Testcontainers 管理容器生命周期；用固定的容器镜像版本并复用；合理设置启动超时与重试；用 Testcontainers 的模块化（如 JDBC、Kafka）简化配置；测试数据用独立 schema/库隔离；避免在每个测试重复启动容器（复用单例容器）；结合 CI 环境配置 Docker 资源。价值是"真实依赖 + 可复现 + 隔离"，提升集成测试可信度。

Testcontainers 让集成测试用真实容器依赖，避免内存/模拟差异。最佳实践是容器复用、版本固定、资源隔离、CI 适配。

• jextract 概念
• 从 C 头文件生成绑定
• 工作流

jextract 是 Project Panama 的工具，从 C 头文件（.h）自动生成 Java 绑定代码，替代手写原生绑定。工作流：给定 C 头文件与库，jextract 解析头文件生成 Java 类（包含 MethodHandle、MemoryLayout、SymbolLookup 的封装），再在 Java 中通过生成的绑定调用原生库。它简化了 FFM 的样板代码，让开发者声明式获得原生函数与结构体的 Java 封装。生成代码可重复使用，是 FFM 生态的代码生成工具。适用于快速集成原生库。

jextract 从 C 头文件生成 Java 绑定，自动化 FFM 集成。工作流是"头文件 → 生成绑定 → Java 调用"，减少手写样板。