为什么 Netty 不使用 JDK 自带的 ThreadLocal，而是实现了自己的 FastThreadLocal？请说明其设计动机和实现原理。

回答思路

1. 【回答框架 1】JDK ThreadLocal 每个线程维护一个 ThreadLocalMap，键为 ThreadLocal 实例的弱引用，查找时需哈希定位，多个 ThreadLocal 可能冲突，性能上有一定开销。Netty 的使用场景是每个 Channel 绑定大量线程局部变量，访问频繁，需要更高性能。
2. 【回答框架 2】FastThreadLocal 的核心是与 FastThreadLocalThread 绑定，该线程内部使用数组存储值，数组下标直接由 FastThreadLocal 的索引决定，避免了哈希计算和冲突处理，查找是 O(1) 操作，提升访问速度。
3. 【回答框架 3】FastThreadLocal 通过静态 AtomicInteger 为每个实例分配唯一索引，线程启动时创建足够大的数组，后续 set/get 直接按下标访问，删除时置空。若在普通线程中使用，会退化为 JDK ThreadLocal 机制，保证兼容性。
4. 【回答框架 4】FastThreadLocal 与 JDK ThreadLocal 差异在于底层存储结构和查找方式，前者以空间换时间，适合 Netty 高并发场景。使用时需确保线程是 FastThreadLocalThread 类型，否则性能优势不成立。
5. 【回答框架 5】内存回收方面，JDK ThreadLocal 用弱引用防泄漏，FastThreadLocal 依赖线程销毁和数组清理，使用时需注意避免线程池中长时间存活导致内存占用。总体看，FastThreadLocal 是针对性优化，并非普遍替代。
6. 【关键点 1】FastThreadLocal 使用数组下标映射代替哈希映射，get/set 时间复杂度为 O(1)。
7. 【关键点 2】基于 FastThreadLocalThread 线程，每个线程内部维护数组存储值，索引全局唯一。
8. 【关键点 3】在非 FastThreadLocalThread 上会回退到 JDK ThreadLocal 实现。
9. 【关键点 4】以空间换时间，适合高并发、大量线程局部变量的场景。
10. 【关键点 5】线程池复用线程时需显式清理，否则可能导致内存残留（内存泄漏风险）。
11. 【易错点 1】认为 FastThreadLocal 在任何线程上都有性能优势，实际需 FastThreadLocalThread 配合。
12. 【易错点 2】忽视线程池中线程复用导致旧值残留，可能引发业务 bug 或内存泄漏。
13. 【易错点 3】将 FastThreadLocal 与 JDK ThreadLocal 完全对立，其实两者机制可并存，且 FastThreadLocal 设计目标特定。