java对象池化必须用强引用作为责任主体，因软/弱引用无法保证对象可用性：软引用仅在oom前回收，弱引用每次gc即回收，均不可靠；生产级池（如hikaricp）依赖强引用+显式容量控制、状态重置与空闲驱逐机制来平衡复用与内存安全。
Java 中的对象重用，特别是通过引用类型配合池化技术实现的重用，核心在于“避免重复创建 + 安全复位 + 按需供给”。它不是简单地把对象存起来再拿出来，而是结合引用语义（尤其是软/弱引用）与池管理机制，让高成本对象在可控范围内被反复使用，同时不拖垮内存。
为什么普通引用不适合长期池化
强引用（Strong Reference）是默认引用类型。如果池中对象全用强引用持有，即使业务已不再需要这些对象，JVM 也无法回收它们——哪怕内存紧张，也会导致池无限膨胀、OOM 风险上升。所以纯强引用池必须靠人工控制大小（如 maxIdle/minIdle），且需严格归还逻辑，否则极易泄漏。
软引用与弱引用在池中的实际作用
它们不是用来替代池管理的，而是作为“弹性兜底”手段：
- 软引用（SoftReference）：适合缓存类池，比如预加载的模板对象、配置快照。JVM 在发生内存不足（即将 OOM 前）才会回收软引用对象。可用于实现“尽力而为”的对象复用——有则快，无则重建，不影响主流程。
- 弱引用（WeakReference）：适合生命周期极短、可随时丢弃的中间对象池，例如日志格式化器、临时字符串缓冲器。GC 每次运行都可能清空它，因此必须搭配快速重建逻辑，不能依赖其稳定性。
注意：二者都不能直接用于线程池或数据库连接池这类需状态可控、必须可用的场景——因为连接/线程一旦被 GC 回收，业务就直接失败了。
真正可靠的池化依赖强引用 + 显式生命周期管理
生产级池（如 HikariCP、commons-pool2、自定义 ThreadPoolExecutor）全部基于强引用构建，但通过以下机制规避内存压力：
- 设置明确的池容量边界（maxTotal / maxIdle / minIdle）
- 对象借出前重置状态（如 Connection.clearWarnings()、Buffer.clear()）
- 空闲对象定时驱逐（eviction policy）和有效性检测（validationQuery）
- 拒绝策略防止过载（如 CallerRunsPolicy）
换句话说：强引用是“责任主体”，软/弱引用只是“辅助减压阀”，不能本末倒置。
典型误用：拿 Integer 缓存当对象池
像 Integer.valueOf(127) 返回缓存实例，这是 JVM 内部对小整数做的软性优化，属于常量池范畴，不是应用层对象池。它不可配置、不可扩展、不适用于自定义类型。试图模仿它去缓存业务对象（如 new User()）反而会因未重置字段引发数据污染——池化必须配套 reset() 或 factory.create() 逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
