对象池不适用于短生命周期轻量对象，应优先用于初始化重、销毁贵、复用率高的资源；需严格配平borrow/return、同步销毁、轻量校验，并注意pool2到pool3的接口迁移。
对象池不是万能的，别在短生命周期对象上硬套 GenericObjectPool
用 GenericObjectPool 管理 String、LocalDateTime 这类轻量对象，性能反而更差——池化开销（锁、计数、状态检查）远超对象创建成本。JVM 对小对象的 new 操作已高度优化，逃逸分析+TLAB 让分配近乎零成本。
真正适合池化的，是初始化重、销毁贵、复用率高的资源：数据库连接、HTTP 客户端实例、大缓冲区（ByteBuffer）、解析器（如 JsonParser）。
-
maxIdle和minIdle要结合实际并发波动设，盲目设高会导致空闲对象长期占内存不释放 - 务必重写
Factory.makeObject()，避免在里面做阻塞操作（如远程调用），否则池获取会卡住整个线程 -
testOnBorrow开启后每次取对象都执行validateObject()，网络类资源建议开，纯内存对象可关以减压
连接泄漏是 GenericObjectPool 最常见的线上事故源头
现象是：池里活跃对象数持续上涨，getNumActive() 越来越高，最终所有线程卡在 borrowObject() 超时，抛出 NullPointerException 或 IllegalStateException: Pool not open —— 实际是等不到可用对象。
根本原因几乎全是没配 try-with-resources 或漏掉 returnObject() 调用。
立即学习“Java免费学习笔记（深入）”；
- 必须确保每个
borrowObject()都有对应且被执行的returnObject()，哪怕发生异常；推荐用try-finally包裹 - 不要在
returnObject()后继续使用该对象，它可能已被销毁或重置；invalidateObject()才是主动报废的正确方式 - 开启
setTestWhileIdle(true)+setTimeBetweenEvictionRunsMillis(30000)，能定期清理已断开但未归还的连接
BasePooledObjectFactory 的 destroyObject() 里别写异步清理逻辑
池在回收对象时会同步调用 destroyObject()，如果这里启动新线程去关连接、清缓存，主线程认为销毁已完成，对象内存被回收，但后台任务还在跑——容易引发 Connection closed 或 NPE。
典型错误：在 destroyObject() 里调用 httpClient.closeAsync() 而非 httpClient.close()。
- 销毁逻辑必须同步、快速、幂等；耗时操作（如网络挥手、磁盘刷盘）应提前在业务层完成
- 若底层资源本身不支持同步关闭（如某些老版本 Netty
EventLoopGroup），需升级依赖或换池化策略 - 重写
validateObject()时，只做轻量健康检查（如socket.isConnected()），别发起真实请求
从 commons-pool2 升级到 commons-pool3 会破掉自定义工厂
commons-pool3 彻底移除了 BasePooledObjectFactory，改用函数式接口 PooledObjectFactory<t></t>，方法签名全变了：makeObject() 变成 create()，destroyObject() 拆成 destroy(PooledObject<t>)</t>，连返回类型都不同。
如果你的项目里有继承 BasePooledObjectFactory 的子类，直接升级 JAR 会编译失败，运行时则报 NoClassDefFoundError。
- 迁移时不能只改依赖，必须重写工厂类，把原逻辑映射到新接口的四个方法中
-
commons-pool3默认启用软引用驱逐（SoftReference），对堆敏感场景要显式关掉：setEvictionPolicyClassName("org.apache.commons.pool3.impl.DefaultEvictionPolicy") - 别为了“新”而升级——
pool2在 JDK 8–17 下稳定运行多年，除非你明确需要pool3的虚拟线程适配或更细粒度的统计回调
