设计模式之对象池模式

对象池模式

对象池模式, 或者称为对象池服务, 其意图为: 通过循环使用对象, 减少资源在初始化和释放时的昂贵损耗(这里的"昂贵"可能是时间效益(如性能), 也可能是空间效益(如并行处理), 在大多情况下, 指性能)

简单的说, 在需要时,从池中提取,不用时,放回池中,等待下一个请求. 典型的例子是连接池和线程池.

类图如下:

其中角色如下:

  1. ObjectPool 对象池角色: 提供对象池, 其中有两个公共方法, checkOut负责从池中提取对象, checkIn负责回收对象(很多时候,checkIn已经自动化处理,不需要显示生命, 如连接池)

对象池实例代码:

这是一个简单的对象池实现,在实际应用中还需要考虑池的最小值、最大值、池化对象状态(若有,重点考虑)、异常处理(如满池情况)等方面,特别是池化对象状态,若是有状态的业务对象则需要重点关注.



把对象池化的本意是期望一次性初始化所有对象,减少对象在初始化上的昂贵性能开销,从而提高系统整体性能. 然而池化处理本身也要付出代价, 因此,并非任何情况下都适合采用对象池化.

通常情况下, 在重复生成对象的操作成为影响性能的关键时,才适合进行对象池化.但是若池化所能带来的性能提高并不显著或重要的话,建议放弃对象池化技术,以保持代码的简明,转而使用更好的硬件来提高性能为佳.

对象池技术在Java领域已经非常成熟, 只要做过企业级开发的人员,基本都用过 C3P0、DBCP、Proxool等连接池, 这是对象池模式的典型应用. 在实际开发中若需要对象池, 建议使用 common-pool 工具包来实现, 简单、快捷、高效.



可以关注一下鄙人的公众号, 谢谢各位了!

原文地址:https://www.cnblogs.com/hujingnb/p/10171628.html

时间: 2024-10-10 21:11:18

设计模式之对象池模式的相关文章

游戏开发设计模式之对象池模式(unity3d 示例实现)

前篇:游戏开发设计模式之命令模式(unity3d 示例实现) 博主才学尚浅,难免会有错误,尤其是设计模式这种极富禅意且需要大量经验的东西,如果哪里书写错误或有遗漏,还请各位前辈指正. 原理:从一个固定的池中重用对象,来提升性能和内存的使用,而不是一个一个的分配内存在释放它们.当你需要创造大量重复的对象,而且经常使用这些对象,你就要考虑使用对象池了,因为反复创建销毁就是一个内存反复分配与释放的过程,很容易产生内存碎片.在主机和移动端与PC相比内存稀缺,我们都希望游戏能够更加稳定,而不能有效的管理内

java/android 设计模式学习笔记(5)---对象池模式

这次要介绍一下对象池模式(Object Pool Pattern),这个模式为常见 23 种设计模式之外的设计模式,介绍的初衷主要是在平时的 android 开发中经常会看到,比如 ThreadPool 和 MessagePool 等. 在 java 中,所有对象的内存由虚拟机管理,所以在某些情况下,需要频繁创建一些生命周期很短使用完之后就可以立即销毁,但是数量很大的对象集合,那么此时 GC 的次数必然会增加,这时候为了减小系统 GC 的压力,对象池模式就很适用了.对象池模式也是创建型模式之一,

《Unity3D》通过对象池模式,管理场景中的元素

池管理类有啥用? 在游戏场景中,我们有时候会需要复用一些游戏物体,比如常见的子弹.子弹碰撞类,某些情况下,怪物也可以使用池管理,UI部分比如:血条.文字等等 这些元素共同的特性是:存在固定生命周期,使用比较频繁,场景中大量使用. 所以,我们就通过池管理思路,在游戏初始化的时候,生成一个初始的池,存放我们要复用的元素, 当要用到时,从池中取出:生命周期结束,放回到池中. 代码 这个池的参数有两个:1池中存放的元素 2 池的初始容量(如果池不够了,则会按照这个容量进行扩展) 代码如下 using S

对象池模式

1.对象池技术并没有限制说只能创建一个对象,而且这种技术同样适用于创建固定数量的对象,然而,这种情况下,你就得面对如何共享对象池里的对象这种问题. 当创建多个对象会的代价会很大的时候,可以考虑使用对象池技术,目前已有的技术比如:线程池技术.数据库连接池技术 2.UML图(astah/jude)下载地址: 3.模拟一个数据库连接池进行实现: 实现的接口: 1 package com.xinye.test.pool; 2 /** 3 * 用户需要的实际的东西都实现这个接口 4 * @author x

C++设计模式 之 “对象性能” 模式:Singleton、Flyweight

“对象性能”模式 面向对象很好地解决了“抽象”的问题,但是必不可免地要付出一定的代价.对于通常情况来讲,面向对象的成本大都可以忽略不计.但是某些情况,面向对象所带来的成本必须谨慎处理. 典型模式 # Singleton # Flyweight Part 1 单件模式(单例模式) 动机 #在软件系统中,经常有这样一些特殊的类,必须保证它们在系统中只存在一个实例,才能确保他们的逻辑正确性.以及良好的效率. #如何绕过常规的构造器,提供一种机制来保证一个类只有一个实例? #这应该是类设计者的责任,而不

C++设计模式 之 “对象创建”模式:Factory Method

part 0 “对象创建”模式 通过“对象创建” 模式绕开new,来避免对象创建(new)过程中所导致的紧耦合(依赖具体类),从而支持对象创建的稳定.它是接口抽象之后的第一步工作. 典型模式 Factory Method Abstract Factory Prototype Builder Part 1 Factory Method 工厂方法 动机(Motivation) 在软件系统中,经常面临着创建对象的工作:由于需求的变化,需要创建的对象的具体类型经常变化. 如何应对这种变化?如何绕过常规的

享元模式(对象池模式)

我在网上也看到了一些实现,感觉都不是太满意,所以按照我的理解写了一份 1 <?php 2 3 /** 4 * 具体的需要缓存的对象, 因new的代价太高昂, 所以做一个缓存 5 */ 6 class Worker 7 { 8 public function __construct() 9 { 10 //做一些代价高昂的事情,比如创建线程 11 } 12 13 public function run($class, $functionName) 14 { 15 //对$class做一些事情 16

Java多线程设计模式(4)线程池模式

前序: Thread-Per-Message Pattern,是一种对于每个命令或请求,都分配一个线程,由这个线程执行工作.它将“委托消息的一端”和“执行消息的一端”用两个不同的线程来实现.该线程模式主要包括三个部分: 1,Request参与者(委托人),也就是消息发送端或者命令请求端 2,Host参与者,接受消息的请求,负责为每个消息分配一个工作线程. 3,Worker参与者,具体执行Request参与者的任务的线程,由Host参与者来启动. 由于常规调用一个方法后,必须等待该方法完全执行完毕

游戏编程模式-对象池

“使用固定的对象池重用对象,取代单独的分配和释放对象,以此来达到提升性能和优化内存使用的目的.” 动机 假设我们正在致力于游戏的视觉效果优化.当英雄释放魔法时,我们想让一个火花在屏幕上炸裂.这通常需要一个粒子系统(一个用来生成大量小的图形并在它们生存周期产生动画的引擎)来实现.而这个粒子系统实现这个火花的时候会产生大量的粒子,我们需要非常快速的创建这些粒子同时在这些粒子“死亡”的时候释放这些粒子对象.在这里,我们会碰到一个严重的问题——内存碎片化. 碎片化地害处 为游戏和移动设备编程在很多方面都