知识卡片
对象池化本身有代价只在重建成本真正高昂时才值得引入
内容
[[对象池模式用一次性预加载消解高并发下的重复查询瓶颈]]的通用结构是checkOut/ checkIn两方法，典型应用是数据库连接池、线程池，这类对象创建销毁开销巨大。但池化本身 有代价：需维护容量、追踪占用状态、处理满池异常，有状态对象归还时还需重置。发散：判断 准则是只有重复创建/销毁确是性能瓶颈时才值得池化，收益不显著就保持简单；真要用优先选 成熟实现而非手写。
参考来源
- 位置：《设计模式之禅（第2版）》第38章《新模式》38.2.2-38.2.3节（源文件：_epub-src/text/part0162.html）
- 结论依据：原文给出对象池模式意图"通过循环使用对象，减少资源在初始化和释放时的昂贵损耗"，并在最佳实践中提醒"池化处理本身也要付出代价，因此，并非任何情况下都适合采用对象池化……若池化所能带来的性能提高并不显著或重要的话，建议放弃对象池化技术，以保持代码的简明……在实际开发中若需要对象池，建议使用common-pool工具包来实现"。
- 原始内容：通过循环使用对象，减少资源在初始化和释放时的昂贵损耗……池化处理本身也要付出代价，因此，并非任何情况下都适合采用对象池化……若池化所能带来的性能提高并不显著或重要的话，建议放弃对象池化技术，以保持代码的简明，转而使用更好的硬件来提高性能为佳……建议使用common-pool工具包来实现，简单、快捷、高效。