String.intern() 的详细理解

                    字符串intern 的作用以及具体案例

前提：如果想了解字符串的intern操作产生的影响，必须首先知道字符串对象的创建方式，一般字符串有四种创建方式，如下

String str1 = "123";  // 字面两直接赋值
String str2 = new String("123"); // 调用字符串构造方法生成对象
String str3 = str1 + str2;
final String str4 = "123";
final String str5 = "456";
String  str6 = str4 + str5;

第一种，如果使用字符串字面量进行字符串对象的创建，那么会首先去常量池中查看是否已经存在了该值，如果存在的话，直接返回该对象的引用。

第二种， 该方法对直接在堆上分配内存空间创建该对象

第三种， jvm 会在编译的时候将其优化为StringBuilder 的拼接，其也生成了新对象 StringBuilder 注意该对象是线程不安全的

第四种，由于是字符串常量拼接，故jvm会在编译期将其替换为为常量，就相当于第一种方式，先去常量池查看

首先针对于JDK1.6以及以前的jvm来说

讲完了字符串的创建方式，接下来就要进入主题了，string的intern 方法的作用是去字符串常量池查看是否存在该字符串对象（equals() 方法进行比较） 如果存在，那么直接返回该对象的引用，如果不存在那么直接在常量池中创建该对象，并返回该对象的地址（该操作为JDK1.6及以前）

如果理解了字符串的创建方式以及intern 方法的作用，那么对于字符串的intern 用途应该也有了一部分理解。

    那么作用呢！！！

那么在平常中，我们有哪些地方能使用到该特性呢。

想象这样一个需求，在一个接口中，该接口被多个线程并发访问的，该接口主要做了以下工作，查询的时候是根据广告的类型查询符合该类型的广告，如果查询到广告，那么就返回该广告列表，但同时，由于请求量比较的大，为了增加查询速度，同时减轻数据库的负担，我们在该层加入redis ， 这样，我们也许会这样做，首先，我们去redis 查询该类型的广告，如果存在那么就直接返回，如果不存在，那么我们需要 为该广告类型加锁，进行锁定，然后进行二次查询redis(二次判空，保证查询排队的线程，只要又一个查询到了，那么其他的就不用查库了)，然后查询数据库，在存入到redis 中，返回即可，其他的线程，如果当时在排队，那么在二次判空的时候就可以拿到值，其他的则在第一次查询redis 中直接拿到了值，

but,但是  要注意，在接口中，我们是在线程内部的，我们锁定的只是一个字符串对象，

首先，相同值的字符串，也可能是不同的对象，

其次，我们是在线程内部，由于线程的栈封闭性，我们锁定的该字符串值，其他线程可能并不知道，

所以，我们需要一种策略，值相同的字符串就是一个对象，同时又是线程可见性的，那么字符串常量池就是一个很好的媒介，我们可以使用intern 方法得到字符串常量池的引用，这样就保证了 字符串值相同，那么就是一个对象，同时又是线程可见性的。

但是，我们最后还是不要直接用字符串的intern 方法，为什么呢，首先在 jdk1.6 以及之前，字符串常量池是存储在永久代中的，也就是方法区中的，如果频繁使用该方法，那么就会造成该区域内存占有过大，造成垃圾收集器的gc 从而影响程序的运行，那么难道就真的不能使用吗？ 当然不是，如果不能用，那么讲这么多，还有什么意义呢， java 有一个很好的工具库， guava ，这个库学习java的真的很值得学习以下，其中封装了很多的工具类，其中很多平时都很常用，其中就有一个 类，

Interner<String> pool = Interners.newWeakInterner();

该类对 intern 做了很多的优化，使用弱引用包装了你传入的字符串类型，所以，这样就不会对内存造成较大的影响， 可以使用该类的 pool.intern(str) 来进行对字符串intern, 好了，这样就解决了内存的问题了，那么我们使用了该优点，并且避免了内存占用问题，完美解决。

如果有这样的需求，可以考虑这个思路。

业务代码大致逻辑如下

if (redis 存在) {
           直接return;
  } else { // 不存在

            Interner<String> pool = Interners.newWeakInterner();

              synchronized (pool.intern(str)) {

                    if(redis 存在){

                        return;

                     }else{

                        查库，入redis,返回

                     }

                }

}

对于字符串常量池的解释，在jdk1.6 以及之前，字符串常量池是存在于永久代中的（方法区），在jdk 1.7  常量池移动到了堆空间中，并且常量池中只存储字符串的引用，不再存储字符串值，在jdk1.8 又进行改变，字符串常量池已经不存在，又出现了一个metaSpace(元空间) 。