ConcurrentHashMap 读操作遇到 ForwardingNode 时会自动跳转至新表继续查找，由 get() 内部的 Node.find() 完成重哈希与遍历，支持多轮递归跳转；ForwardingNode 无业务数据，val 和 key 均为 null，不可直接读取；其 nextTable 必不为 null，且并发读无竞争、零同步开销。
ConcurrentHashMap 读操作遇到 ForwardingNode 时怎么走
遇到 ForwardingNode 不代表出错，而是说明当前桶已完成迁移，读操作必须跳转到新表继续查找。这个过程完全由 get() 方法内部自动完成，无需手动干预。
关键逻辑在 Node.find(int h, Object k) 方法里：它拿到 nextTable 后，重新计算哈希在新表中的索引（(n - 1) & h，其中 n 是新表长度），再遍历对应桶的链表或红黑树。如果新表该位置仍是 ForwardingNode（比如正在多轮扩容），就继续递归跳转，直到找到真实数据节点或返回 null。
为什么不能直接读 forwardingNode.val 或调用 get() 外部逻辑处理
ForwardingNode 继承自 Node，但它的 val 字段是 null，key 也是 null —— 它本身不存业务数据，只起状态标识和跳转作用。硬取 forwardingNode.val 会得到 null，且绕过跳转逻辑会导致查不到数据。
- 所有 public API（如
get()、containsKey()）都已内置对ForwardingNode的识别和转发 - 手动 cast 成
ForwardingNode并调用find()属于内部协议，行为不保证稳定，JDK 版本升级可能调整其实现 - 调试时看到
ForwardingNode出现在 dump 中，只说明那个桶位已完成迁移，不是 bug
forwardingNode.nextTable 为空或被置 null 会怎样
nextTable 在扩容启动时就被初始化并赋值给 ConcurrentHashMap.nextTable 字段；只有当整个扩容彻底完成、新表正式接替旧表后，nextTable 才会被设为 null。所以只要看到 ForwardingNode，它的 nextTable 一定非空。
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
唯一例外是扩容中途 OOM 导致初始化失败，此时 sizeCtl 被设为 Integer.MAX_VALUE，后续 put 会拒绝写入，但已有 ForwardingNode 不会出现 nextTable == null —— 因为构造函数强制要求传入非空数组。
并发读时多个线程同时 hit 同一个 ForwardingNode 会不会卡住
不会。ForwardingNode.find() 是纯计算逻辑，无锁、无 CAS、不修改任何状态，只是读 nextTable + 重哈希 + 遍历。多个线程并发调用互不影响，甚至能共享 CPU cache line。
真正有竞争的是写操作（put、remove）遇到 ForwardingNode 时触发的协助扩容（helpTransfer），那才会去争抢迁移任务段。读操作全程零同步开销。
真正容易被忽略的是：ForwardingNode 的存在意味着你看到的「当前 table」只是扩容过程中的中间态，它的结构不可靠、不可遍历、也不该被反射或序列化工具直接读取 —— 所有业务代码必须通过标准 Map 接口访问，否则会踩进状态不一致的坑。
