38.2 对象池模式
上周二,师兄过来找我,他负责运维一个大型新闻网站,说是网站出现性能,让我帮忙分析调优。我这几天正好闲得手痒,同时又卖个人情,何乐而不为呢。于是我们俩就到机房蹲点,追查问题。
38.2.1 正确的池化
简单说明一下该系统的场景,这是一个专业的新闻追踪网站,关注的是专业新闻的深度,在行业内具有相当大的影响力。最近一段时间内出现偶发性缓慢,从监控情况上看,响应时间在2秒以上,由于最近软硬件环境都没有变更过,因此直觉判断:最快捷、直观的解决方案就是增加DB硬件设备。但由于东家是穷惯了,不同意在没有彻查问题之前而依靠增强硬件来解决问题,于是我们这些软件工程师就忙活起来了。
网站首页内容基本都是静态的(轮询生成),唯一的动态部分是网站的激励语,比如“积一时之跬步,臻千里之遥程”、“业精于勤,荒于嬉;行成于思,毁于随”等励志语句,这是一个简单的SQL随机查询结果,表中的数量在5000条左右,而且结构简单,查询性能不是问题。示例代码如代码清单38-29所示。
代码清单38-29 无缓存的SQL随机读取
@Service
public class WisdomProvider {
@Autowire
private WisdomDao wisdomDao;
public String getOneWord() {
return wisdomDao.randomOneWisdom();
}
}
对于代码中的@Service、@Autowire注解,做过Spring开发的都懂,这是一个典型的三层架构,WisdomDao的randomOneWisdom方法是通过数据库随机函数查询一条记录。在跟踪过程中,发现高峰期数据库连接偶尔出现占满情况,而且都是查询该表(顺便说下,该数据库的随机查询算法有缺陷),问题找到了:每一次访问都会直接查询数据库,没有缓存。通常情况下,这没有问题,但是在高并发的情况下,例如在10万PV的压力下服务器基本就垮掉了,这是非常严重的问题。
怎么解决呢?好办,引入一个对象池,把这5000条记录(根据评估最多不超过20000条记录)在启动时直接加载到内存中,在需要时再从内存中取得,以后查询不再与数据库交互。示例代码如代码清单38-30所示。
代码清单38-30 增加缓存后的随机读取
@Service
public class WisdomProvider {
@Autowire
private WisdomDao wisdomDao;
private List<String> wisdoms = null;
@PostConstruct
public void init() {
wisdoms = wisdomDao.getAll();
}
public String getOneWord() {
return RandomUtils.getOne(wisdoms);
}
}
@PostConstruct注解的作用是Spring容器在启动完毕后,直接执行init方法,一次性读取所有的数据,然后在应用运行期间不再与数据库交互,直接从List列表中获取数据。通过这样的修正,系统性能有了大幅提升,在不增加硬件的情况下,彻底解决了性能问题。这就是对象池模式。
38.2.2 对象池模式的意图
对象池模式,或者称为对象池服务,其意图如下:
通过循环使用对象,减少资源在初始化和释放时的昂贵损耗[[1]](#)。
注意 这里的“昂贵”可能是时间效益(如性能),也可能是空间效益(如并行处理),在大多的情况下,“昂贵”指性能。
简单地说,在需要时,从池中提取;不用时,放回池中,等待下一个请求。典型例子是连接池和线程池,这是我们开发中经常接触到的。类图如图38-6所示。
![](https://box.kancloud.cn/2016-08-14_57b0037257c05.jpg)
图38-6 对象池模式通用类图
对象池提供两个公共的方法:checkOut负责从池中提取对象,checkIn负责把回收对象(当然,很多时候checkIn已经自动化处理,不需要显式声明,如连接池),对象池代码如代码清单38-31所示。
代码清单38-31 对象池示例代码
public abstract class ObjectPool<T> {
//容器,容纳对象
private Hashtable<T, ObjectStatus> pool = new Hashtable<T, ObjectStatus>();
//初始化时创建对象,并放入到池中
public ObjectPool() {
pool.put(create(), new ObjectStatus());
}
//从Hashtable中取出空闲元素
public synchronized T checkOut() {
//这是最简单的策略
for (T t : pool.keySet()) {
if (pool.get(t).validate()) {
pool.get(t).setUsing();
return t;
}
}
return null;
}
//归还对象
public synchronized void checkIn(T t) {
pool.get(t).setFree();
}
class ObjectStatus {
//占用
public void setUsing() {
}
//释放
public void setFree() {
//注意:若T是有状态,则需要回归到初始化状态
}
//检查是否可用
public boolean validate() {
return false;
}
}
//创建池化对象
public abstract T create();
}
这是一个简单的对象池实现,在实际应用中还需要考虑池的最小值、最大值、池化对象状态(若有的话,需要重点考虑)、异常处理(如满池情况)等方面,特别是池化对象状态,若是有状态的业务对象则需要重点关注。
38.2.3 最佳实践
把对象池化的本意是期望一次性初始化所有对象,减少对象在初始化上的昂贵性能开销,从而提高系统整体性能。然而池化处理本身也要付出代价,因此,并非任何情况下都适合采用对象池化。
通常情况下,在重复生成对象的操作成为影响性能的关键因素时,才适合进行对象池化。但是若池化所能带来的性能提高并不显著或重要的话,建议放弃对象池化技术,以保持代码的简明,转而使用更好的硬件来提高性能为佳。
对象池技术在Java领域已经非常成熟,只要做过企业级开发的人员,基本都用过C3P0、DBCP、Proxool等连接池,也配置过minPoolSize、maxPoolSize等参数,这是对象池模式的典型应用。在实际开发中若需要对象池,建议使用common-pool工具包来实现,简单、快捷、高效。
[[1]](#)原文是Avoid expensive acquisition and release of resources by recycling objects that are no longer in use。
- 前言
- 第一部分 大旗不挥,谁敢冲锋——6大设计原则全新解读
- 第1章 单一职责原则
- 1.2 绝杀技,打破你的传统思维
- 1.3 我单纯,所以我快乐
- 1.4 最佳实践
- 第2章 里氏替换原则
- 2.2 纠纷不断,规则压制
- 2.3 最佳实践
- 第3章 依赖倒置原则
- 3.2 言而无信,你太需要契约
- 3.3 依赖的三种写法
- 3.4 最佳实践
- 第4章 接口隔离原则
- 4.2 美女何其多,观点各不同
- 4.3 保证接口的纯洁性
- 4.4 最佳实践
- 第5章 迪米特法则
- 5.2 我的知识你知道得越少越好
- 5.3 最佳实践
- 第6章 开闭原则
- 6.2 开闭原则的庐山真面目
- 6.3 为什么要采用开闭原则
- 6.4 如何使用开闭原则
- 6.5 最佳实践
- 第二部分 真刀实枪 ——23种设计模式完美演绎
- 第7章 单例模式
- 7.2 单例模式的定义
- 7.3 单例模式的应用
- 7.4 单例模式的扩展
- 7.5 最佳实践
- 第8章 工厂方法模式
- 8.2 工厂方法模式的定义
- 8.3 工厂方法模式的应用
- 8.4 工厂方法模式的扩展
- 8.5 最佳实践
- 第9章 抽象工厂模式
- 9.2 抽象工厂模式的定义
- 9.3 抽象工厂模式的应用
- 9.4 最佳实践
- 第10章 模板方法模式
- 10.2 模板方法模式的定义
- 10.3 模板方法模式的应用
- 10.4 模板方法模式的扩展
- 10.5 最佳实践
- 第11章 建造者模式
- 11.2 建造者模式的定义
- 11.3 建造者模式的应用
- 11.4 建造者模式的扩展
- 11.5 最佳实践
- 第12章 代理模式
- 12.2 代理模式的定义
- 12.3 代理模式的应用
- 12.4 代理模式的扩展
- 12.5 最佳实践
- 第13章 原型模式
- 13.2 原型模式的定义
- 13.3 原型模式的应用
- 13.4 原型模式的注意事项
- 13.5 最佳实践
- 第14章 中介者模式
- 14.2 中介者模式的定义
- 14.3 中介者模式的应用
- 14.4 中介者模式的实际应用
- 14.5 最佳实践
- 第15章 命令模式
- 15.2 命令模式的定义
- 15.3 命令模式的应用
- 15.4 命令模式的扩展
- 15.5 最佳实践
- 第16章 责任链模式
- 16.2 责任链模式的定义
- 16.3 责任链模式的应用
- 16.4 最佳实践
- 第17章 装饰模式
- 17.2 装饰模式的定义
- 17.3 装饰模式应用
- 17.4 最佳实践
- 第18章 策略模式
- 18.2 策略模式的定义
- 18.3 策略模式的应用
- 18.4 策略模式的扩展
- 18.5 最佳实践
- 第19章 适配器模式
- 19.2 适配器模式的定义
- 19.3 适配器模式的应用
- 19.4 适配器模式的扩展
- 19.5 最佳实践
- 第20章 迭代器模式
- 20.2 迭代器模式的定义
- 20.3 迭代器模式的应用
- 20.4 最佳实践
- 第21章 组合模式
- 21.2 组合模式的定义
- 21.3 组合模式的应用
- 21.4 组合模式的扩展
- 21.5 最佳实践
- 第22章 观察者模式
- 22.2 观察者模式的定义
- 22.3 观察者模式的应用
- 22.4 观察者模式的扩展
- 22.5 最佳实践
- 第23章 门面模式
- 23.2 门面模式的定义
- 23.3 门面模式的应用
- 23.4 门面模式的注意事项
- 23.5 最佳实践
- 第24章 备忘录模式
- 24.2 备忘录模式的定义
- 24.3 备忘录模式的应用
- 24.4 备忘录模式的扩展
- 24.5 最佳实践
- 第25章 访问者模式
- 25.2 访问者模式的定义
- 25.3 访问者模式的应用
- 25.4 访问者模式的扩展
- 25.5 最佳实践
- 第26章 状态模式
- 26.2 状态模式的定义
- 26.3 状态模式的应用
- 第27章 解释器模式
- 27.2 解释器模式的定义
- 27.3 解释器模式的应用
- 27.4 最佳实践
- 第28章 享元模式
- 28.2 享元模式的定义
- 28.3 享元模式的应用
- 28.4 享元模式的扩展
- 28.5 最佳实践
- 第29章 桥梁模式
- 29.2 桥梁模式的定义
- 29.3 桥梁模式的应用
- 29.4 最佳实践
- 第三部分 谁的地盘谁做主 ——设计模式PK
- 第30章 创建类模式大PK
- 30.1 工厂方法模式VS建造者模式
- 30.2 抽象工厂模式VS建造者模式
- 第31章 结构类模式大PK
- 31.1 代理模式VS装饰模式
- 31.2 装饰模式VS适配器模式
- 第32章 行为类模式大PK
- 32.1 命令模式VS策略模式
- 32.2 策略模式VS状态模式
- 32.3 观察者模式VS责任链模式
- 第33章 跨战区PK
- 33.1 策略模式VS桥梁模式
- 33.2 门面模式VS中介者模式
- 33.3 包装模式群PK
- 第四部分 完美世界 ——设计模式混编
- 第34章 命令模式+责任链模式
- 34.2 混编小结
- 第35章 工厂方法模式+策略模式
- 35.2 混编小结
- 第36章 观察者模式+中介者模式
- 36.2 混编小结
- 第五部分 扩展篇
- 第37章 MVC框架
- 37.2 最佳实践
- 第38章 新模式
- 38.1 规格模式
- 38.2 对象池模式
- 38.3 雇工模式
- 38.4 黑板模式
- 38.5 空对象模式
- 附录 23种设计模式彩图