设计模式系列往期精彩文章

无场景不设计
有这样的一个项目需求：给客户A做一个产品展示网站，客户A的朋友感觉效果不错，也希望做这样的产品展示网站，但是要求都有些不同：

有客户要求以新闻的形式发布
有客户人要求以博客的形式发布
有客户希望以微信公众号的形式发布

如果是你的话，你会怎么去解决这个需求呢，思考一分钟…….

传统的解决方案：

直接复制粘贴一份，然后根据客户不同要求，进行定制修改
给每个网站租用一个空间
方案设计示意图

传统方案解决网站展现项目-问题分析

需要的网站结构相似度很高，而且都不是高访问量网站，如果分成多个虚拟空间来处理，相当于一个相同网站的实例对象很多，造成服务器的资源浪费
解决思路：整合到一个网站中，共享其相关的代码和数据，对于硬盘、内存、CPU、数据库空间等服务器资源都可以达成共享，减少服务器资源
对于代码来说，由于是一份实例，维护和扩展都更加容易
上面的解决思路就可以使用享元模式来解决

好了我们直接步入正题…….

享元模式

基本概念

享元模式（FlyWeight Pattern）又叫蝇量模式，运用共享技术有效支撑大量细粒度的对象

常用于系统底层开发，解决系统性能问题。比如：数据库连接池，里面都是创建好的连接对象,在这些对象中有我们需要的则可以直接拿来使用，避免重新创建，如果没有我们需要的，则重新创建一个。

享元模式能够解决重复对象浪费内存的问题,当系统中有大量相似的对象，需要缓冲池。不需要总是创建对象，可以从缓冲池里面拿。这样可以降低系统内存，提高使用效率。

享元模式经典的使用场景就是池技术，String常量池、数据库连接池、缓冲池等都是享元模式的应用。享元模式是池技术的重要实现方式。

享元模式原理类图

对原理图的说明-即(模式的角色及职责)

FlyWeight：是一个抽象的享元角色，它是产品的抽象类，同时定义出对象的外部状态和内部状态的接口或实现。

ConcreteFlyWeight是具体的享元角色，是具体的产品类，实现抽象角色定义的相关业务

UnSharedConcreteFlyWeight是不可共享的角色，一般不会出现在享元工厂里面

FlyWeightFactory 享元工厂类，用于构建于池子容器(集合)，同时提供从池中获取对象的方法

上面刚刚有提到外部状态和内部状态，
什么是外部状态和内部状态?

比如围棋、五子棋、跳棋，它们都有大量的棋子对象，围棋和五子棋只有黑白两色，跳棋颜色多一点，所以棋子颜色就是棋子的内部状态；而各个棋子之间的差别就是位置的不同，当我们落子后，落子颜色是定的，但位置是变化的，所以棋子坐标就是棋子的外部状态

享元模式提出了两个要求：细粒度和共享对象。这里就涉及到内部状态和外部状态了，即将对象的信息分为两个部分：内部状态和外部状态

内部状态指对象共享出来的信息，存储在享元对象内部且不会随环境的改变而改变

外部状态指对象得以依赖的一个标记，是随环境改变而改变的、不可共享的状态。

举个例子

围棋理论上有361个空位可以放棋子，每盘棋都有可能有两三百个棋子对象产生，因为内存空间有限，一台服务器很难支持更多的玩家玩围棋游戏，如果用享元模式来处理棋子，那么棋子对象就可以减少到只有两个实例，这样就很好的解决了对象的开销问题

好了关于享元模式的理论知识就讲到这里了，接下来我们使用享元模式来解决一下针对上面所提到的需求(网站的展现项目)吧。

享元模式的应用实例

代码

WebSite

public abstract class WebSite {

	public abstract void use();//抽象方法
}

ConcreteWebSite

//具体网站
public class ConcreteWebSite extends WebSite {

	//共享的部分，内部状态
	private String type = ""; //网站发布的形式(类型)

	
	//构造器
	public ConcreteWebSite(String type) {
		
		this.type = type;
	}


	@Override
	public void use() {
		// TODO Auto-generated method stub
		System.out.println("网站的发布形式为:" + type + " 在使用中 .. );
	}
	
	
}

WebSiteFactory

// 网站工厂类，根据需要返回压一个网站
public class WebSiteFactory {

	
	//集合， 充当池的作用
	private HashMap<String, ConcreteWebSite> pool = new HashMap<>();
	
	//根据网站的类型，返回一个网站, 如果没有就创建一个网站，并放入到池中,并返回
	public WebSite getWebSiteCategory(String type) {
		if(!pool.containsKey(type)) {
			//就创建一个网站，并放入到池中
			pool.put(type, new ConcreteWebSite(type));
		}
		
		return (WebSite)pool.get(type);
	}
	
	//获取网站分类的总数 (池中有多少个网站类型)
	public int getWebSiteCount() {
		return pool.size();
	}
}

Client

public class Client {

	public static void main(String[] args) {
		// TODO Auto-generated method stub

		// 创建一个工厂类
		WebSiteFactory factory = new WebSiteFactory();

		// 客户要一个以新闻形式发布的网站
		WebSite webSite1 = factory.getWebSiteCategory("新闻");

		
		webSite1.use();

		// 客户要一个以博客形式发布的网站
		WebSite webSite2 = factory.getWebSiteCategory("博客");

		webSite2.use();

		// 客户要一个以博客形式发布的网站
		WebSite webSite3 = factory.getWebSiteCategory("博客");

		webSite3.use();

		// 客户要一个以博客形式发布的网站
		WebSite webSite4 = factory.getWebSiteCategory("博客");

		webSite4.use());
		
		System.out.println("网站的分类共=" + factory.getWebSiteCount());
	}

}

截止到上述代码，也简单实现了享元模式，但是缺少了某个元素，不知道有没有发现呢……
其实就是外部状态：我们的用户，因为用户是不一样的。
UML类图：

根据UML类图我们进行简单地改造一下吧.

User

public class User {
	
	private String name;

	
	public User(String name) {
		super();
		this.name = name;
	}

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}
	
	
}

WebSite

public abstract class WebSite {

	public abstract void use(User user);//抽象方法
}

ConcreteWebSite

//具体网站
public class ConcreteWebSite extends WebSite {

	//共享的部分，内部状态
	private String type = ""; //网站发布的形式(类型)

	
	//构造器
	public ConcreteWebSite(String type) {
		
		this.type = type;
	}


	@Override
	public void use(User user) {
		// TODO Auto-generated method stub
		System.out.println("网站的发布形式为:" + type + " 在使用中 .. 使用者是" + user.getName());
	}
	
	
}

Client

public class Client {

	public static void main(String[] args) {
		// TODO Auto-generated method stub

		// 创建一个工厂类
		WebSiteFactory factory = new WebSiteFactory();

		// 客户要一个以新闻形式发布的网站
		WebSite webSite1 = factory.getWebSiteCategory("新闻");

		
		webSite1.use();

		// 客户要一个以博客形式发布的网站
		WebSite webSite2 = factory.getWebSiteCategory("博客");

		webSite2.use();

		// 客户要一个以博客形式发布的网站
		WebSite webSite3 = factory.getWebSiteCategory("博客");

		webSite3.use();

		// 客户要一个以博客形式发布的网站
		WebSite webSite4 = factory.getWebSiteCategory("博客");

		webSite4.use());
		
		System.out.println("网站的分类共=" + factory.getWebSiteCount());
	}

}

讲到这里享元模式的基本概念和实际应用案例到这里就讲完了，不知道是否有理解透彻，为了让大家理解的更加透彻，我来给大家看一下享元模式在JDK源码中的使用

源码解析之享元模式在JDK中的应用

分析源码之前先给大家看一段小案例：

public static void main(String[] args) {
		
		Integer x = Integer.valueOf(127); // 得到 x实例，类型 Integer
		Integer y = new Integer(127); // 得到 y 实例，类型 Integer
		Integer z = Integer.valueOf(127);//..
		Integer w = new Integer(127);
		
		System.out.println(x.equals(y)); // 大小，true
		System.out.println(x == y ); //  false
		System.out.println(x == z ); // true
		System.out.println(w == x ); // false
		System.out.println(w == y ); // false
		
		
		Integer x1 = Integer.valueOf(200);
		Integer x2 = Integer.valueOf(200);
		System.out.println("x1==x2" + (x1 == x2)); // false
		
		
	}

我相信大家对以上的小案例并不陌生吧，因为这是很基础的面试题。

那么我们思考一个问题：

为什么x==z是true呢，它们两个都是通过valueOF返回一个实例，按理说两个实例的地址应该不是一样的为什么会是true呢？我们来看一下valueOf的源码

通过源码我们不难看出里面有两种情况:

如果i的范围大于等于 IntegerCache.low并且i的范围小于等于IntegerCache.high，就会在一个缓冲池cache里面获取，这里low= -128 high= 127

如果不在以上所述的范围内，则会new一个

如果通过 Integer.valueOf(x) 创建，在 -128 — 127 直接，就是使用享元模式返回,如果不在这个范围内就创建一个。

小结:

在valueOf 方法中，先判断值是否在 IntegerCache 中，如果不在，就创建新的Integer(new), 否则，就直接从缓存池返回
valueOf 方法，就使用到享元模式
如果使用valueOf 方法得到一个Integer 实例，范围在 -128 – 127 ，执行速度比 new 快

享元模式讲到这里，相关的概念、实际应用案例，以及源码分析已经讲完了。我们来简单地总结一下吧。

总结

享元模式的注意事项和细节：

在享元模式这样理解，“享”就表示共享，“元”表示对象
系统中有大量对象，这些对象消耗大量内存，并且对象的状态大部分可以外部化时，我们就可以考虑选用享元模式
用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象，用HashMap/HashTable存储
享元模式大大减少了对象的创建，降低了程序内存的占用，提高效率
享元模式提高了系统的复杂度。需要分离出内部状态和外部状态，而外部状态具有固化特性，不应该随着内部状态的改变而改变，这是我们使用享元模式需要注意的地方.
使用享元模式时，注意划分内部状态和外部状态，并且需要有一个工厂类加以控制。
享元模式经典的应用场景是需要缓冲池的场景，比如 String常量池、数据库连接池