对象池仅在对象创建开销大、生命周期短且线程复用率高时真正降低gc压力；pojo池化反而因锁和校验开销拖慢性能，常见错误包括线程溢出、脏对象复用和吞吐下降。
对象池在Java里什么时候真能省GC，什么时候纯属添乱
对象池不是万能加速器，它只在特定场景下压低GC压力：对象创建开销大（比如 ByteBuffer、HttpClient 连接）、生命周期短且集中、线程复用率高。但多数 POJO（如 User、OrderItem）用池子反而拖慢——JVM 对轻量对象的分配早已优化到纳秒级，而池子引入的锁、引用计数、回收校验全是额外开销。
常见错误现象：OutOfMemoryError: unable to create new native thread（池子没设上限）、StaleObjectException（对象被复用前没重置状态）、吞吐量不升反降（竞争 ConcurrentLinkedQueue 或 SynchronizedPool）。
- 用
Apache Commons Pool2时，务必重写makeObject()和validateObject()，否则脏对象直接污染后续调用 - 池大小别硬写死——按线程数 × 平均并发请求数 × 1.5 估算，再用
jstat -gc观察YGC频次是否下降 - 避免池化
String、Integer等已由 JVM 缓存的对象，它们自带常量池
ThreadLocal 不是线程安全银弹，它泄漏的静默方式很致命
ThreadLocal 的核心价值是“免同步地隔离线程内状态”，但它本身不解决对象生命周期问题。泄漏通常发生在 Web 容器（如 Tomcat）中：线程被复用，但 ThreadLocal 变量未手动 remove()，导致旧请求的 Connection、DateFormat 持久驻留在线程里，最终 OutOfMemoryError: Metaspace 或堆内存缓慢上涨。
使用场景明确：每个线程需独占一个昂贵对象（如 SimpleDateFormat、JsonParser），且该线程生命周期可控（比如自建线程池）。Servlet 容器环境必须配合过滤器或拦截器做兜底清理。
立即学习“Java免费学习笔记（深入）”；
- 永远用
static final ThreadLocal<t></t>声明，避免实例变量引用导致 GC 不掉 - 在
try-finally块末尾强制threadLocal.remove()，别依赖set(null) - 注意
InheritableThreadLocal的父子线程传递行为——异步任务中可能意外透传敏感上下文
不可变对象为什么不能随便标 final，得看字段类型
声明 final class User 只保证类不被继承，不等于对象不可变。真正不可变需要同时满足：所有字段 private final、无修改方法、构造函数不泄露 this 引用、内部可变组件（如 ArrayList、byte[]）必须防御性拷贝。
典型翻车点：final List<string> tags = new ArrayList();</string> —— 字段不可变，但 tags.add("new") 依然能改内容；final Date createTime = new Date(); —— Date 自身可变，外部调用 setTime() 就破防。
- 优先用 JDK9+ 的
List.of()、Map.copyOf()替代手动包装Collections.unmodifiableXXX() - 对数组字段，构造时用
Arrays.copyOf()拷贝，getter 返回Arrays.copyOf(arr, arr.length) - 谨慎复用第三方库的“不可变”类——
Guava's ImmutableList是真的不可变，但Spring's MutablePropertyValues名字就写着别信
三者混用时最易忽略的边界：状态残留与可见性
对象池 + ThreadLocal 是常见组合（比如每个线程持有一个 PooledByteBuffer），但这里藏着双重风险：池中对象若含 ThreadLocal 引用，回收时没清理会泄漏；反之，ThreadLocal 里存了池对象，线程结束却忘了归还，池就慢慢枯竭。
更隐蔽的是内存可见性：final 字段保障初始化安全，但池对象复用时若靠 reset() 方法清空状态，这个方法必须包含 volatile 写或 Unsafe.storeFence()，否则其他线程可能看到旧值。
- 池对象的
reset()方法里，对所有非final字段赋默认值后，加一句UNSAFE.storeFence()（JDK9+）或Thread.onSpinWait()提示编译器 - 避免在
ThreadLocal中存池对象本身——改用ThreadLocal<supplier>></supplier>延迟获取，确保每次用的都是干净实例 - 用
JFR（Java Flight Recorder）抓取ObjectAllocationInNewTLAB事件，比看 GC 日志更能定位到底是对象分配多，还是老对象没被回收
