文章目录
1. 定义
面向对象技术可以很好地解决一些灵活性或可扩展性问题,但在很多情况下需要在系统中增加类和对象的个数.当对象数量太多时,将导致运行代价过高,带来性能下降等问题.享元模式正是为解决这一类问题而诞生的
享元模式(Flyweight Pattern)又称为轻量级模式,是对象池的一种实现.类似于线程池,线程池可以避免不停的创建和销毁多个对象,消耗性能.提供了减少对象数量从而改善应用所需的对象结构的方式.其宗旨是共享细粒度对象,将多个对同一对象的访问集中起来,不必为每个访问者创建一个单独的对象,以此来降低内存的消耗,属于结构型模式.
原文∶Use sharing to support large numbers of fine-grained objects efficiently
解释∶使用共享对象可有效地支持大量的细粒度的对象
享元模式把一个对象的状态分成内部状态和外部状态,内部状态即是不变的,外部状态是变化的;然后通过共享不变的部分,达到减少对象数量并节约内存的目的
享元模式模式的本质是缓存共享对象,降低内存消耗
首先我们来看享元模式的通用 UML 类图∶
从类图上看,享元模式有三个参与角色∶
- 抽象享元角色(Flyweight)∶享元对象抽象基类或者接口,同时定义出对象的外部状态和内部状态的接口或实现;
- 具体享元角色(ConcreteFlyweight)∶实现抽象角色定义的业务.该角色的内部状态处理应该与环境无关,不能出现会有一个操作改变内部状态,同时修改了外部状态;
- 享元工厂(FlyweightFactory)∶负责管理享元对象池和创建享元对象
2. 应用场景
当系统中多处需要同一组信息时,可以把这些信息封装到一个对象中,然后对该对象进行缓存,这样,一个对象就可以提供给多处需要使用的地方,避免大量同一对象的多次创建,消耗大量内存空间
享元模式其实就是工厂模式的一个改进机制,享元模式同样要求创建一个或一组对象,并且就是通过工厂方法生成对象的,只不过享元模式中为工厂方法增加了缓存这一功能.主要总结为以下应用场景
- 常常应用于系统底层的开发,以便解决系统的性能问题
- 系统有大量相似对象,需要缓冲池的场景
在生活中的享元模式也很常见,比如各中介机构的房源共享,再比如全国社保联网
3. 使用享元模式实现共享池业务
下面我们举个例子,我们每年春节为了抢到一张回家的火车票都要大费周折,进而出现了很多刷票软件,刷票软件会将我们填写的信息缓存起来,然后定时检查余票信息.抢票的时候,我们肯定是要查询下有没有我们需要的票信息,这里我们假设一张火车的信息包含∶出发站,目的站,价格,座位类别.现在要求编写一个查询火车票查询伪代码,可以通过出发站,目的站查到相关票的信息
比如要求通过出发站,目的站查询火车票的相关信息,那么我们只需构建出火车票类对象,然后提供一个查询出发站,目的站的接口给到客户进行查询即可,具体代码如下,创建 ITicket 接口
public interface ITicket {
void showInfo(String bunk);
}
然后,创建 TrainTicket 接口
public class TrainTicket implements ITicket {
private String from;
private String to;
private int price;
public TrainTicket(String from, String to) {
this.from = from;
this.to = to;
}
public void showInfo(String bunk) {
this.price = new Random().nextInt(500);
System.out.println(String.format("%s->%s：%s 价格：%s 元", this.from, this.to, bunk, this.price));
}
}
最后创建 TicketFactory 类
public class TicketFactory {
public static ITicket queryTicket(String from, String to) {
return new TrainTicket(from, to);
}
}
客户端代码
public class Test {
public static void main(String[] args) {
ITicket ticket = TicketFactory.queryTicket("北京西", "长沙");
ticket.showInfo("硬座");
ticket = TicketFactory.queryTicket("北京西", "长沙");
ticket.showInfo("软座");
ticket = TicketFactory.queryTicket("北京西", "长沙");
ticket.showInfo("硬卧");
}
}
分析上面的代码,我们发现客户端进行查询时,系统通过 TicketFactory 直接创建一个火车票对象,但是这样做的话,当某个瞬间如果有大量的用户请求同一张票的信息时,系统就会创建出大量该火车票对象,系统内存压力骤增.而其实更好的做法应该是缓存该票对象,然后复用提供给其他查询请求,这样一个对象就足以支撑数以千计的查询请求,对内存完全无压力,使用享元模式可以很好地解决这个问题.我们继续优化代码,只需在 TicketFactory 类中进行更改,增加缓存机制
public class TicketFactory {
private static Map<String, ITicket> sTicketPool = new ConcurrentHashMap<String,ITicket>();
public static ITicket queryTicket(String from, String to) {
String key = from + "->" + to;
if (TicketFactory.sTicketPool.containsKey(key)) {
System.out.println("使用缓存：" + key);
return TicketFactory.sTicketPool.get(key);
}
System.out.println("首次查询，创建对象: " + key);
ITicket ticket = new TrainTicket(from, to);
TicketFactory.sTicketPool.put(key, ticket);
return ticket;
}
}
运行结果如下
首次查询，创建对象: 北京西->长沙
北京西->长沙：硬座价格：200 元
使用缓存：北京西->长沙
北京西->长沙：软座价格：324 元
使用缓存：北京西->长沙
北京西->长沙：硬卧价格：450 元
可以看到,除了第一次查词创建对象后,后续查词相同车次票信息都是使用缓存对象,无需创建新对象了.来看一下类结构图
其中 ITicket 就是抽象享元角色,TrainTicket 就是具体享元角色,Ticketfactory 就是享元工厂.有些小伙伴一定会有疑惑了,这不就是注册式单例模式吗?对,这就是注册式单例模式.虽然,结构上很像,但是享元模式的重点在结构上,而不是在创建对象上.后面看看享元模式在 JDK 源码中的一个应用,大家应该就能彻底清除明白了
再比如,我们经常使用的数据库连接池,因为我们使用 Connection 对象时主要性能消耗在建立连接和关闭连接的时候,为了提高 Connection 在调用时的性能,我们和将 Connection 对象在调用前创建好缓存起来,用的时候从缓存中取值,用完再放回去,达到资源重复利用的目的.来看下面的代码
public class ConnectionPool {
private Vector<Connection> pool;
private String url = "jdbc:mysql://localhost:3306/test";
private String username = "root";
private String password = "root";
private String driverClassName = "com.mysql.jdbc.Driver";
private int poolSize = 100;
public ConnectionPool() {
pool = new Vector<Connection>(poolSize);
try{
Class.forName(driverClassName);
for (int i = 0; i < poolSize; i++) {
Connection conn = DriverManager.getConnection(url,username,password);
pool.add(conn);
}
}catch (Exception e){
e.printStackTrace();
}
}
public synchronized Connection getConnection(){
if(pool.size() > 0){
Connection conn = pool.get(0);
pool.remove(conn);
return conn;
}
return null;
}
public synchronized void release(Connection conn){
pool.add(conn);
}
}
这样的连接池,普遍应用于开源框架,有效提升底层的运行性能
4. 在源码中的应用
4.1 String 中的享元模式
Java 中将 String 类定义为 final(不可改变的),ⅣM 中字符串一般保存在字符串常量池中,java 会确保一个字符串在常量池中只有一个拷贝,这个字符串常量池在 JDK6.0 以前是位于常量池中,位于永久代,而在 JDK7.0 中,ⅣM 将其从永久代拿出来放置于堆中
我们做一个测试
public class StringTest {
public static void main(String[] args) {
String s1 = "hello";
String s2 = "hello";
String s3 = "he" + "llo";
String s4 = "hel" + new String("lo");
String s5 = new String("hello");
String s6 = s5.intern();
String s7 = "h";
String s8 = "ello";
String s9 = s7 + s8;
System.out.println(s1==s2);//true
System.out.println(s1==s3);//true
System.out.println(s1==s4);//false
System.out.println(s1==s9);//false
System.out.println(s4==s5);//false
System.out.println(s1==s6);//true
}
}
String 类的 final 修饰的,以字面量的形式创建 String 变量时,VM 会在编译期间就把该字面量""hello"放到字符串常量池中,由 Java 程序启动的时候就已经加载到内存中了.这个字符串常是池的特点就是有且只有一份相同的字面量,如果有其它相同的字面量,ⅣM 则返回这个字面量的引用,如果没有相同的字面量,则在字符串常量池创建这个字面量并返回它的引用
由于 s2 指向的字面量"hello 在常量池中已经存在了(s1 先于 s2),于是 VM 就返回这个字面量绑定的引用,所以 s1==s2.
s3 中字面量的拼接其实就是"hello",ⅣM 在编译期间就已经对它进行优化,所以 s1 和 s3 也是相等的.
s4 中的 newString(“lo”")生成了两个对象,lo,newString(“lo”),lo 存在字符串常量池,newString(“lo”)存在堆中,Strings4=“hel”+newString(“lo”)实质上是两个对象的相加,编译器不会进行优化,相加的结果存在堆中,而 s1 存在字符串常量池中,当然不相等.s1==s9 的原理一样.
s4==s5 两个相加的结果都在堆中,不用说,肯定不相等.
s1s6 中,s5.intern0 方法能使一个位于堆中的字符串在运行期间动态地加入到字符串常量池中(字符串常量池的内容是程序启动的时候就已经加载好了),如果字符串常量池中有该对象对应的字面量,则返回该字面量在字符串常量池中的引用,否则,创建复制一份该字面量到字符串常量池并返回它的引用.因此 s1s6 输出 true
4.2 Integer 中的享元模式
再举例一个大家都非常熟悉的对象 Integer,也用到了享元模式,其中暗藏玄机,我们来看个例子
public class IntegerTest {
public static void main(String[] args) {
Integer a = Integer.valueOf(100);
Integer b = 100;
Integer c = Integer.valueOf(1000);
Integer d = 1000;
System.out.println("a==b:" + (a==b));
System.out.println("c==d:" + (c==d));
}
}
大家猜猜看它的运行结果是什么?我们跑完程序之后才发现总有些不对,得到了一个意向不到的结果,其运行结果如下∶
a==b:true
c==d:false
之所以得到这样的结果,是因为 Integer 用到的享元模式,我们来看 Integer 的源码
public final class Integer extends Number implements comparable<Integer> {
...
public static Integer valueof(int i){
if(1 >= IntegerCache.low && i <= IntegerCache.high) {
return IntegerCache.cache[i＋(-IntegerCache.low)];
}
return new Integer(i);
}
...
}
我们发现 Integer 源码中的 valueOf0 方法做了一个条件判断,如果目标值在-128 到 127 之间,则直接从缓存中取值,否则新建对象.那 JDK 为何要这样做呢?因为在-128 到 127 之间的数据在 int 范围内是使用最频繁的,为了节省频繁创建对象带来的内存消耗,这里就用到了享元模式,来提高性能
4.3 Long 中的享元模式
public final clss Long extends Number implements Coparable<Long> {
public static Long valueof(long var0) {
return var0 >= -128L && var0 <= 127L ? Long.LongCache.cache[(int)var0 + 128] : new Long(var0);
}
private static class LongCache {
private LongCache(){}
static final Long cache[]= new Long[-(-128) + 127 ＋ 1];
static{
for(int i = 0; i < cache.length; i++) {
cache[i]= new Long(i -128);
}
}
}
}
同理,Long 中也有缓存,不过不能指定缓存最大
4.4 ApacheCommonsPool2 中的享元模式
对象池化的基本思路是∶将用过的对象保存起来,等下一次需要这种对象的时候,再拿出来重复使用,从而在一定程度上减少频繁创建对象所造成的开销.用于充当保存对象的"容器"的对象,被称为"“对象池”(ObjectPool,或简称 Pool)
ApacheCommonsPool 实现了对象池的功能.定义了对象的生成,销毁,激活,钝化等操作及其状态转换,并提供几个默认的对象池实现.有几个重要的对象
- PooledObject(池对象)∶用于封装对象(如∶线程,数据库连接,TCP 连接),将其包裹成可被池管理的对象
- PooledObjectfactory(池对象工厂)∶定义了操作 PooledObject 实例生命周期的一些方法,PooledObjectFactory 必须实现线程安全
- ObjectPool(对象池)∶ObjectPool 负责管理 PooledObject,如∶借出对象,返回对象,校验对象,有多少激活对象,有多少空闲对象
private final Map<IdentityWrapper<T>, PooledObject<T>> allObjects;
这里我们就不分析其具体源码了
5. 内部状态和外部状态
享元模式的定义为我们提出了两个要求∶细粒度和共享对象.因为要求细粒度对象,所以不可避免地会使对象数量多且性质相近,此时我们就将这些对象的信息分为两个部分∶内部状态和外部状态
内部状态指对象共享出来的信息,存储在享元对象内部并且不会随环境的改变而改变;外部状态指对象得以依赖的一个标记,是随环境改变而改变的,不可共享的状态
比如,连接池中的连接对象,保存在连接对象中的用户名,密码,连接 url 等信息,在创建对象的时候就设置好了,不会随环境的改变而改变,这些为内部状态.而每个连接要回收利用时,我们需要给它标记为可用状态,这些为外部状态
6. 优缺点
6.1 优点
- 减少对象的创建,降低内存中对象的数量,降低系统的内存,提高效率
- 减少内存之外的其他资源占用
6.2 缺点
- 关注内,外部状态,关注线程安全问题
- 使系统,程序的逻辑复杂化