一、不变性模式
在并发编程的世界里，共享变量的线程安全问题永远是一个无法避免且不得不面对的问题，如果只有读的情况，那么永远也不会出现线程安全的问题，因为多线程读永远是线程安全的，但是多线程读写一定会存在线程安全的问题。那既然这么说是不是通过只读就能解决并发问题呢？其实最简单的办法就是让共享变量只有读操作，而没有写操作。这个办法如此重要，以至于被上升到了一种解决并发问题的设计模式：不变性(Immutability) 模式。
所谓不变性，简单来讲，就是对象一旦被创建之后，状态就不再发生变化。换句话说，就是变量一旦被赋值，就不允许修改了(没有写操作) ；没有修改操作，也就是保持了不变性。
二、不可变性的类
在java中，如果要实现-一个不可变的对象是很简单的，将其定义为final 即可，同样类也是如此，只需要通过final来修饰某个类即可。同时将一个类所有的属性都设置成final的，并且只允许存在只读方法，那么这个类基本上就具备不可变性了。更严格的做法是这个类本身也是final 的，也就是不允许继承。因为子类可以覆盖父类的方法，有可能改变不可变性，所以推荐你在实际工作中，使用这种更严格的做法。
我们在日常开发中，已经在不知不觉中享受不可变模式带来的好处，例如经常用到的String、Long、Integer、 Double等基础类型的包装类都具备不可变性，这些对象的线程安全性都是靠不可变性来保证的。
仔细翻看基础类型的包装类的声明、属性和方法，你会发现它们都严格遵守不可变类的三点要求:类是final 的，属性也是final 的。同样的一旦某个类被final修饰，其本身就不能被继承了，也就无法重写其方法，即方法是只读的。
既然说方法是只读的，但是Java的String方法也有类似字符替换操作，这个不就已经改变了value[]变量了吗?因为value[]是这么定义的。我们结合String的源代码(jdk8)来看一下 jdk是如何处理这个问题的，下面是源码的截图
它实际上是重新定义了一个新的buf[]来保存数据，这样在最后返回数据的时候确实没有修改原始的value[]，而是将替换后的字符串作为返回值返回了。通过分析String的实现，你可能已经发现了，如果具备不可变性的类，需要提供类似修改的功能，具体该怎么操作呢？做法很简单，那就是创建一个新的不可变对象，这是与可变对象的一个重要区别，可变对象往往是修改自己的属性。
而这里所有的修改操作都创建一个新的不可变对象。但是一个问题的解决必然会带来的新的问题，那就是这样势必在每次使用的时候都会创建新的对象，那岂不是无端的降低了系统的性能，浪费了系统的资源?这个时候享元模式就可以大显神通了。
三、享元模式
享元模式你可能实际开发中使用的很少，它是这么定义的：享元模式(Flyweight Pattern) ：是一种软件设计模式。它使用共享物件，用来尽可能减少内存使用量以及分享资讯给尽可能多的相似物件；它适合用于只是因重复而导致使用无法令人接受的大量内存的大量物件。通常物件中的部分状态是可以分享。常见做法是把它们放在外部数据结构，当需要使用时再将它们传递给享元。用一句直白话来概括就是：通过对象池的技术来避免重复的创建对象。这就好比是Spring中的容器(单例模式下)，我们的对象都交给Spring容器来管理，这样我们再使用的时候只需要到容器中去拿即可，而不是每次都去创建新的对象。
利用享元模式可以减少创建对象的数量，从而减少内存占用。Java 语言里面Long、Integer、Short、 Byte等这些基本数据类型的包装类都用到了享元模式。享元模式本质上其实就是一个个对象池，利用享元模式创建对象的逻辑也很简单：创建之前，首先去对象池里看看是不是存在；如果已经存在，就利用对象池里的对象；如果不存在，就会新创建一个对象， 并且把这个新创建出来的对象放进对象池里。