享元模式
面向对象技术可以很好地解决一些灵活性或可扩展性问题，但在很多情况下需要在系统中增加类和对象的个数。当对象数量太多时，将导致运行代价过高，带来性能下降等问题。享元模式正是为解决这一类问题而诞生的。
定义
享元模式（Flyweight Pattern）又称为轻量级模式，是对象池的一种实现。类似于线程池，线程池可以避免不停的创建和销毁对象，消耗性能。提供了减少对象数量从而改善应用所需的对象结构的方式。其宗旨是共享细粒度对象，将多个对同一对象的访问集中起来，不必为每个访问者创建一个单独的对象。以此来降低对内存的消耗，属于结构型模式。
享元模式把一个对象的状态分为内部状态和外部状态，内部状态即是不变的，外部状态是变化的。然后通过共享不变的部分，达到减少对象数量并节约内存的目的。
享元模式的本质是缓存共享对象，降低内存消耗。
享元模式的应用场景
当系统中多处需要同一组信息时，可以把这些信息封装到一个对象中，然后对该对象进行缓存，这样，一个对象就可以提供给多处需要使用的地方，避免大量对同一对象的多次创建，消耗过多的内存空间。
享元模式其实就是工厂模式的一个改进机制，享元模式同样要求创建一个或一组对象，并且就是通过工厂方法生成对象的，只不过享元模式中为工厂方法增加了缓存这一功能。主要总结为以下应用场景：
- 尝尝应用于系统底层的开发，以便解决系统的性能问题；
- 系统有大量相似对象、需要缓冲池的场景；
在生活中，享元模式也很常见，比如各个中介机构的房源共享，再比如全国社保联网。
使用享元模式实现共享池业务
下面举个例子，我们每年春节为了抢到一张回家的火车票，都大费周章，进而出现了很多刷票软件，刷票软件会将我们的信息缓存起来，然后定时检查余票信息。抢票的时候，我们肯定要查询下有没有我们需要的票信息，这里我们假设一张火车票的信息包含：出发站，目的地，价格，座位类别。现在要求编写一个查询火车票的的伪代码，可以通过出发站，目的站查到相关的票信息。
比如要求通过出发站，目的站查询火车票的相关信息，那么我们只需要构建出火车票类对象，然后提供一个查询出发站，目的站的接口给客户端进行查询即可，具体代码如下：
首先创建Iticket 接口
public interface ITicket {
/**
* 票的信息
* @param bunk
*/
void showInfo(String bunk);
}
然后创建火车票信息接口：
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;
}
@Override
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));
}
}
最后创建享元工厂类：
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;
}
}
来进行测试：
public static void main(String[] args) {
ITicket ticket = TicketFactory.queryTicket("北京西", "上海");
ticket.showInfo("硬座");
ticket = TicketFactory.queryTicket("北京西", "杭州");
ticket.showInfo("软座");
ticket = TicketFactory.queryTicket("北京西", "杭州");
ticket.showInfo("硬卧");
}
结果：
可以看到，除了第一次查询创建对象之外，当再次查询北京西 -> 杭州 的车票时，直接从缓存你中获取到了。
其中ITicket就是抽象享元角色，TrainTicket就是具体享元角色，TicketFactory就是享元工厂。是不是和注册式单例模式很相似？没错，这就是注册式单例模式，虽然结构上很像，但是享元模式的重点在于结构上，而不是在创建对象上。后面通过分析 JDK源码中的使用，就能区分开了。
享元模式在源码中的应用
1、String 中的享元模式
Java 中 String 类型定义为 final，JVM中字符串一般保存在字符串常量池中，Java 会确保一个字符串在常量池中只有一个拷贝，这个字符串常量池在JDK6.0以前位于常量池中，位于永久代，而在 JDK1.7中，JVM将其从永久代拿出来放到了堆内存中。
看一下测试代码：
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 变量时，JVM 会在编译期间就把该字面量”hello“放到字符串常量池，由 Java程序启动的时候就已经加载到内存中，这个字符串常量池的特点就是有且只有一份相同的字面量，如果有其他相同的字面量，JVM 则直接返回这个字面量的引用，如果没有相同的字面量，则在字符串常量池中创建这个字面量并返回它的引用。
由于s2指向的字面量”hello“在常量池中已经存在了（s1 早于 s2），于是 JVM 就直接返回这个字面量绑定的引用，所以 s1 == s2。
s3中字面量的拼接其实就是”hello“，JVM 在编译期间就已经对它进行了优化，所以 s1 和 s3 也是相等的。
s4 中new String(“lo”)生成了两个对象，”lo“和 new String(“lo”)，lo 存在字符串常量池中，new String(“lo”)存在堆中，String s4 = “hel” + new String(“lo”) 实质上是两个对象的相加，编译器不会进行优化，相加的结果存在堆中，不用说，肯定不相等。
s4 和 s5 两个对象都在堆中，肯定不相等。
s5.intern()方法能使一个堆中的字符串在运行期间动态的加入到字符串常量池中（字符串常量池中的内容是程序启动的时候就已经加载好了），如果字符串常量池中有该对象存在的字面量，则返回该字面量在字符串常量池中的引用，否则，创建复制一份该字面量到字符串常量池并返回它的引用。因此，s1 == s6 输出为 true。
2、Integer 中的享元模式
先来看一个例子：
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));
}
看一下运行结果：
如果没有看过源码的小伙伴，肯定不知道这其中发生了什么，其实这就是Integer 中应用的 享元模式，来看一下源码：
== This method will always cache values in the range -128 to 127 ==
/**
* Returns an {@code Integer} instance representing the specified
* {@code int} value. If a new {@code Integer} instance is not
* required, this method should generally be used in preference to
* the constructor {@link #Integer(int)}, as this method is likely
* to yield significantly better space and time performance by
* caching frequently requested values.
* 这里描述的很清晰，如果传入的是 -128 - 127 之间的数字，会直接从缓存中取
* This method will always cache values in the range -128 to 127,
* inclusive, and may cache other values outside of this range.
*
* @param i an {@code int} value.
* @return an {@code Integer} instance representing {@code i}.
* @since 1.5
*/
public static Integer valueOf(int i) {
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}
我们发现Integer 源码中的 valueOf()方法做了一个判断，如果传入的是 -128 - 127 之间的数字，会直接从缓存中取，否则创建新对象。那么 JDK 为什么要这么做的？因为在-128到 127之间的数据在 int范围内是使用最频繁的，为了节省频繁的创建对象带来的内存消耗，这里就使用了享元模式，来提供性能。
3、Long 中的享元模式
/**
* Returns a {@code Long} instance representing the specified
* {@code long} value.
* If a new {@code Long} instance is not required, this method
* should generally be used in preference to the constructor
* {@link #Long(long)}, as this method is likely to yield
* significantly better space and time performance by caching
* frequently requested values.
*
* Note that unlike the {@linkplain Integer#valueOf(int)
* corresponding method} in the {@code Integer} class, this method
* is <em>not</em> required to cache values within a particular
* range.
*
* @param l a long value.
* @return a {@code Long} instance representing {@code l}.
* @since 1.5
*/
public static Long valueOf(long l) {
final int offset = 128;
if (l >= -128 && l <= 127) { // will cache
return LongCache.cache[(int)l + offset];
}
return new Long(l);
}
享元模式的内部状态和外部状态
享元模式的定义为我们提出了两个要求:细粒度和共享对象。因为要求细粒度对象，所以不可避免地会使对象数量多且性质相近，此时我们就将这些对象的信息分为两个部分:内部状态和外部状态。内部状态指对象共享出来的信息，存储在享元对象内部并且不会随环境的改变而改变;外部状态指对象得以依赖的一个标记，是随环境改变而改变的、不可共享的状态。
比如，连接池中的连接对象，保存在连接对象中的用户名、密码、连接url 等信息，在创建对象的时候就设置好了，不会随环境的改变而改变，这些为内部状态。而每个连接要回收利用时，我们需要给它标记为可用状态，这些为外部状态。
享元模式的优缺点
优点：
- 减少对象的创建，降低内存中对象的数量，降低系统的内存，提高效率；
- 减少内存之外的其他资源占用；
缺点：
- 关注内外部状态，关注线程安全问题；
- 使系统、程序的逻辑复杂化；
上一篇：装饰器模式
扫一扫
415
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
