绝大多数情况下不该自己写对象池，因JVM的GC对短生命周期对象回收已很高效；仅当明确观测到new成为性能瓶颈时才考虑使用Apache Commons Pool2，并需正确实现validateObject、destroyObject，避免池化String等已优化对象，且必须配套监控。
对象池在Java里到底该不该用
绝大多数情况下，别自己写对象池——JVM的GC（尤其是G1或ZGC）对短生命周期对象的回收已经非常高效，盲目池化反而增加复杂度、内存占用和线程竞争风险。只有当你明确观测到 new SomeObject() 成为性能瓶颈（比如每毫秒创建上万次、对象构造开销大、且对象状态可安全复用），才考虑引入。
Apache Commons Pool2 是最稳妥的选型
自己实现对象池容易踩线程安全、泄漏、状态重置不全等坑。直接用 GenericObjectPool + PooledObjectFactory 是成熟路径：
-
create()里只做真正昂贵的操作（如建立Socket连接、解析大JSON模板），不要放简单 new 或 setter 赋值 - 必须重写
validateObject(PooledObject：返回 false 会触发销毁，避免把失效对象还进池子（比如连接已断的) Socket） -
destroyObject(PooledObject里要显式释放资源（) close()、shutdown()），否则池子会吃光文件描述符或连接数 - 设置
setMaxIdle(5)和setMinIdle(0)更安全，避免空闲对象长期驻留导致状态陈旧
String、Integer 这类对象千万别池化
它们本身就被JVM做了优化：String 字面量走常量池，Integer.valueOf(int) 在 [-128, 127] 范围内也缓存了实例。手动池化不仅没收益，还会干扰JIT内联和逃逸分析，反而拖慢吞吐。常见错误是看到“池”字就套用，结果把 new StringBuilder() 也塞进池子——它本就是设计来复用的，直接 setLength(0) 重置比取还快。
池化后必须配监控，否则等于埋雷
没有指标的对象池迟早出事。至少暴露三个值：getNumActive()（正在用的数量）、getNumIdle()（空闲数量）、getCreateCount()（累计创建数）。如果 getNumActive() 长期打满，说明池子太小或对象没被及时归还；如果 getCreateCount() 持续上涨但 getNumIdle() 几乎为0，大概率是 returnObject() 被漏调或者异常吞掉了。别依赖日志——用 JMX 或 Micrometer 接入 Prometheus 才算真正可用。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
