享元模式

1. 概述

定义：运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似对象的开销，从而提高系统资源的利用率。

一句话理解：如果一万个对象里其实只有少数几种"本质不同的样子"，那就只创建这几种，其他地方全部共享引用，用的时候再把"随环境变化的部分"临时传进去。

2. 结构

享元（Flyweight）模式中存在以下两种状态：

1. 内部状态：即不会随着环境的改变而改变的可共享部分；
2. 外部状态：指随环境改变而改变的不可以共享的部分。享元模式的实现要领就是区分应用中的这两种状态，并将外部状态外部化。

享元模式的主要有以下角色：

角色	职责
抽象享元角色（Flyweight）	通常是一个接口或抽象类，声明了具体享元类公共的方法，这些方法可以向外界提供享元对象的内部数据（内部状态），同时也可以通过这些方法来设置外部数据（外部状态）
具体享元（Concrete Flyweight）角色	实现抽象享元类，称为享元对象；在具体享元类中为内部状态提供了存储空间。通常可以结合单例模式来设计具体享元类，为每一个具体享元类提供唯一的享元对象
非享元（Unsharable Flyweight）角色	并不是所有的抽象享元类的子类都需要被共享，不能被共享的子类可设计为非共享具体享元类；当需要一个非共享具体享元类的对象时可以直接通过实例化创建
享元工厂（Flyweight Factory）角色	负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检查系统中是否存在符合要求的享元对象：如果存在则提供给客户，如果不存在则创建一个新的享元对象

3. 案例实现

例：俄罗斯方块

下面的图片是众所周知的俄罗斯方块中的一个个方块。如果在俄罗斯方块这个游戏中，每个不同的方块都是一个实例对象，这些对象就要占用很多的内存空间，下面利用享元模式进行实现。

先来看类图：

代码如下：

俄罗斯方块有不同的形状，我们可以对这些形状向上抽取出 AbstractBox，用来定义共性的属性和行为（形状是内部状态，颜色是外部状态）：

public abstract class AbstractBox {
    public abstract String getShape();

    public void display(String color) {
        System.out.println("方块形状：" + this.getShape() + " 颜色：" + color);
    }
}

接下来就是定义不同的形状了，IBox 类、LBox 类、OBox 类等：

public class IBox extends AbstractBox {

    @Override
    public String getShape() {
        return "I";
    }
}

public class LBox extends AbstractBox {

    @Override
    public String getShape() {
        return "L";
    }
}

public class OBox extends AbstractBox {

    @Override
    public String getShape() {
        return "O";
    }
}

提供了一个工厂类（BoxFactory），用来管理享元对象（也就是 AbstractBox 子类对象）。该工厂类对象只需要一个，所以可以使用单例模式，并给工厂类提供一个获取形状的方法：

import java.util.HashMap;

public class BoxFactory {

    private static HashMap<String, AbstractBox> map;

    private BoxFactory() {
        map = new HashMap<>();
        AbstractBox iBox = new IBox();
        AbstractBox lBox = new LBox();
        AbstractBox oBox = new OBox();
        map.put("I", iBox);
        map.put("L", lBox);
        map.put("O", oBox);
    }

    public static final BoxFactory getInstance() {
        return SingletonHolder.INSTANCE;
    }

    private static class SingletonHolder {
        private static final BoxFactory INSTANCE = new BoxFactory();
    }

    public AbstractBox getBox(String key) {
        return map.get(key);
    }
}

测试类：

public class Client {
    public static void main(String[] args) {
        AbstractBox box1 = BoxFactory.getInstance().getBox("I");
        box1.display("灰色");

        AbstractBox box2 = BoxFactory.getInstance().getBox("L");
        box2.display("绿色");

        AbstractBox box3 = BoxFactory.getInstance().getBox("I");
        box3.display("红色");

        System.out.println("两次获取的I方块是否是同一个对象？" + (box1 == box3));
    }
}

运行输出：

方块形状：I 颜色：灰色
方块形状：L 颜色：绿色
方块形状：I 颜色：红色
两次获取的I方块是否是同一个对象？true

可以看到：形状" I "在享元池中只有一个对象，两次获取是同一个实例；而颜色作为外部状态在使用时传入，同一个享元对象可以呈现不同的颜色。

4. 优缺点和使用场景

优点：

• 极大减少内存中相似或相同对象数量，节约系统资源，提升系统性能；
• 享元模式中的外部状态相对独立，且不影响内部状态。

缺点：

• 为了使对象可以共享，需要将享元对象的部分状态外部化，分离内部状态和外部状态，使程序逻辑复杂。

使用场景：

• 一个系统有大量相同或者相似的对象，造成内存的大量耗费；
• 对象的大部分状态都可以外部化，可以将这些外部状态传入对象中；
• 在使用享元模式时需要维护一个存储享元对象的享元池，而这需要耗费一定的系统资源。因此，应当在需要多次重复使用享元对象时才值得使用享元模式。

5. JDK 源码解析

Integer 类使用了享元模式。我们先看下面的例子：

public class Demo {
    public static void main(String[] args) {
        Integer i1 = 127;
        Integer i2 = 127;

        System.out.println("i1和i2对象是否是同一个对象？" + (i1 == i2));

        Integer i3 = 128;
        Integer i4 = 128;

        System.out.println("i3和i4对象是否是同一个对象？" + (i3 == i4));
    }
}

运行上面代码，结果如下：

为什么第一个输出语句输出的是 true，第二个输出语句输出的是 false？通过反编译软件进行反编译，代码如下：

public class Demo {
    public static void main(String[] args) {
        Integer i1 = Integer.valueOf((int) 127);
        Integer i2 = Integer.valueOf((int) 127);
        System.out.println((String) new StringBuilder().append((String) "i1和i2对象是否是同一个对象？").append((boolean) (i1 == i2)).toString());
        Integer i3 = Integer.valueOf((int) 128);
        Integer i4 = Integer.valueOf((int) 128);
        System.out.println((String) new StringBuilder().append((String) "i3和i4对象是否是同一个对象？").append((boolean) (i3 == i4)).toString());
    }
}

上面代码可以看到，直接给 Integer 类型的变量赋值基本数据类型数据的操作，底层使用的是 valueOf()，所以只需要看该方法即可：

public final class Integer extends Number implements Comparable<Integer> {

    public static Integer valueOf(int i) {
        if (i >= IntegerCache.low && i <= IntegerCache.high)
            return IntegerCache.cache[i + (-IntegerCache.low)];
        return new Integer(i);
    }

    private static class IntegerCache {
        static final int low = -128;
        static final int high;
        static final Integer cache[];

        static {
            int h = 127;
            String integerCacheHighPropValue =
                sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
            if (integerCacheHighPropValue != null) {
                try {
                    int i = parseInt(integerCacheHighPropValue);
                    i = Math.max(i, 127);
                    // Maximum array size is Integer.MAX_VALUE
                    h = Math.min(i, Integer.MAX_VALUE - (-low) - 1);
                } catch (NumberFormatException nfe) {
                }
            }
            high = h;
            cache = new Integer[(high - low) + 1];
            int j = low;
            for (int k = 0; k < cache.length; k++)
                cache[k] = new Integer(j++);
            // range [-128, 127] must be interned (JLS7 5.1.7)
            assert IntegerCache.high >= 127;
        }

        private IntegerCache() {}
    }
}

可以看到 Integer 默认先创建并缓存 -128 ~ 127 之间数的 Integer 对象，当调用 valueOf 时，如果参数在 -128 ~ 127 之间则计算下标并从缓存中返回，否则创建一个新的 Integer 对象。

注意

这也解释了为什么包装类型比较值时应该用 equals() 而不是 ==：== 比较的是对象地址，缓存区间内的值会"碰巧"相同，缓存区间外的值则会返回 false，这种隐式差异非常容易埋坑。

6. 小结

• 享元模式的核心是"区分内部状态与外部状态"：内部状态可共享、进享元池；外部状态随环境变化、由客户端传入；
• 结构上通常是"抽象享元 + 具体享元 + 享元工厂"，工厂内部维护一个 Map 享元池，并常与单例模式配合；
• 它是一种"以时间换空间"的权衡：省下大量重复对象的内存，代价是维护享元池、分离状态的逻辑复杂度；
• JDK 中的典型应用除了 Integer 的 IntegerCache，还有 String 常量池、Boolean.valueOf()、Long.valueOf() 等，理解享元模式后再看这些设计会豁然开朗。