性能调优 15. JVM调优实战及常量池详解

1. 阿里巴巴Arthas详解

1.1. 介绍

‌‌‌　　Arthas 是 Alibaba 在 2018 年 9 月开源的 Java 诊断工具。支持 JDK6+， 采用命令行交互模式，可以方便的定位和诊断线上程序运行问题。

‌‌‌　　Arthas 官方文档十分详细，详见

‌‌‌　　https://alibaba.github.io/arthas

‌‌‌　　注意

‌‌‌　　1. 学习一个知识可以先百度看下入门文章，再看官方文档学习。

1.2. Arthas使用场景

‌‌‌　　得益于 Arthas 强大且丰富的功能，让 Arthas 能做的事情超乎想象。下面仅仅列举几项常见的使用情况，更多的使用场景可以在熟悉了 Arthas 之后自行探索。

‌‌‌　　1. 是否有一个全局视角来查看系统的运行状况？

‌‌‌　　2. 为什么 CPU 又升高了，到底是哪里占用了 CPU ？

‌‌‌　　3. 运行的多线程有死锁吗？有阻塞吗？

‌‌‌　　4. 程序运行耗时很长，是哪里耗时比较长呢？如何监测呢？

‌‌‌　　5. 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？

‌‌‌　　6. 改的代码为什么没有执行到？难道是我没 commit？分支搞错了？

‌‌‌　　7. 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？

‌‌‌　　8. 有什么办法可以监控到 JVM 的实时运行状态？

1.3. Arthas使用

‌‌‌　　1. 下载Arthas的jar包，linux系统下

# github下载arthas
‌‌‌　　wget https://alibaba.github.io/arthas/arthas-boot.jar
# 或者 Gitee 下载
‌‌‌　　wget https://arthas.gitee.io/arthas-boot.jar

‌‌‌　　2. 启动运行，用java -jar运行即可，可以识别机器上所有Java进程。

‌‌‌　　3. 运行一个Arthas测试程序，代码见下方。

‌‌‌　　package com.tuling.jvm;

‌‌‌　　import java.util.HashSet;

‌‌‌　　public class Arthas {

    private static HashSet hashSet = new HashSet();

    public static void main(String[] args) {
        // 模拟 CPU 过高
        cpuHigh();
        // 模拟线程死锁
        deadThread();
        // 不断的向 hashSet 集合增加数据
        addHashSetThread();
    }

    /**
     * 不断的向 hashSet 集合添加数据
     */
    public static void addHashSetThread() {
        // 初始化常量
        new Thread(() -> {
            int count = 0;
            while (true) {
                try {
                    hashSet.add("count" + count);
                    Thread.sleep(1000);
                    count++;
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }

    public static void cpuHigh() {
        new Thread(() -> {
            while (true) {

            }
        }).start();
    }

    /**
     * 死锁
     */
    private static void deadThread() {
        /** 创建资源 */
        Object resourceA = new Object();
        Object resourceB = new Object();
        // 创建线程
        Thread threadA = new Thread(() -> {
            synchronized (resourceA) {
                System.out.println(Thread.currentThread() + " get ResourceA");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread() + "waiting get resourceB");
                synchronized (resourceB) {
                    System.out.println(Thread.currentThread() + " get resourceB");
                }
            }
        });

        Thread threadB = new Thread(() -> {
            synchronized (resourceB) {
                System.out.println(Thread.currentThread() + " get ResourceB");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread() + "waiting get resourceA");
                synchronized (resourceA) {
                    System.out.println(Thread.currentThread() + " get resourceA");
                }
            }
        });
        threadA.start();
        threadB.start();
    }
‌‌‌　　}

‌‌‌　　4. 选择进程对应序号2，进入进程信息操作。

‌‌‌　　5. 输入dashboard可以查看整个进程的运行情况，线程、内存、GC、运行环境信息。

‌‌‌　　6. 输入thread可以查看线程详细情况。

‌‌‌　　7. 输入 thread加上线程ID 可以查看线程堆栈，定位异常地方，比如排查cpu使用高的触发地方。

‌‌‌　　8. 输入 thread -b 可以查看线程死锁。

‌‌‌　　9. 输入 jad加类的全名 可以反编译，这样可以方便我们查看线上代码是否是正确的版本，比如git提交后线上代码对不对。

‌‌‌　　10. 使用 ognl 命令可以查看线上系统变量的值甚至修改。比如修改静态变量属性值，或者调用静态方法。
　　
‌‌‌　　查看属性

‌‌‌　　调用方法

‌‌‌　　更多命令使用可以用help命令查看，或查看文档

‌‌‌　　https://alibaba.github.io/arthas/commands.html#arthas

‌‌‌　　11. 对于集群环境，可以通过别的工具先定位集群某个实例有没问题，在用Arthas。

‌‌‌　　12. linux下关闭Arthas可以用shutdown或者quick命令或者stop，基本这些命令通用用来关闭程序。

2. GC日志详解

2.1. 介绍

‌‌‌　　GC日志是java虚拟机产生的一种描述性的文本日志。就像开发java程序需要输出log日志一样。JAVA 虚拟机用GC日志，来描述垃圾回收过程中运行情况。

‌‌‌　　如果对线上系统不太了解可以尝试分析GC日志。

‌‌‌　　对于java应用可以通过一些配置把程序运行过程中的GC日志全部打印出来，然后分析GC日志得到关键性指标，分析GC原因，调优JVM参数。

‌‌‌　　打印GC日志方法，在JVM参数里增加参数，添加参数如下

‌‌‌　　%t 代表时间。

‌‌‌　　-Xloggc:./gc-%t.log 代表存储日志位置和格式。

‌‌‌　　-XX:+PrintGCDetails 打印GC详细日志。

‌‌‌　　-XX:+PrintGCDateStamps 打印GC日期的时间戳。

‌‌‌　　-XX:+PrintGCTimeStamps 打印GC的时间戳。

‌‌‌　　-XX:+PrintGCCause 打印GC的原因。

‌‌‌　　-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M表示要滚动打印，分段打印到10个文件，每个文件最多保存100M数据，满了下个文件。10个满文件会重新开始覆盖打印。

‌‌‌　　-Xloggc:./gc-%t.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps  -XX:+PrintGCTimeStamps -XX:+PrintGCCause  
‌‌‌　　-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M

‌‌‌　　Tomcat则直接加在JAVA_OPTS变量里，如这样

‌‌‌　　set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m

2.2. 如何分析GC日志

‌‌‌　　1. 在运行程序时候加上对应gc日志，运行命令如下，jar包就不提供只需要明白怎么看就行。

‌‌‌　　java -jar -Xloggc:./gc-%t.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps  -XX:+PrintGCTimeStamps -XX:+PrintGCCause  
‌‌‌　　-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M microservice-eureka-server.jar

　　第一行红框，是项目的配置参数。这里不仅配置了打印GC日志，还有相关的VM内存参数。

‌‌‌　　第二行红框中的是在这个GC时间点发生GC之后相关GC情况。

‌‌‌　　1. 对于2.909： 这是从jvm启动开始计算到这次GC经过的时间，前面还有具体的发生时间日期。

‌‌‌　　2. Full GC(Metadata GC Threshold)指这是一次Full GC，括号里是GC的原因， PSYoungGen是年轻代的GC，ParOldGen是老年代的GC，Metaspace是元空间的GC。

‌‌‌　　3. 6160K->0K(141824K)，这三个数字分别对应GC之前占用年轻代的大小，GC之后年轻代占用，以及整个年轻代的大小。

‌‌‌　　4. 112K->6056K(95744K)，这三个数字分别对应GC之前占用老年代的大小，GC之后老年代占用，以及整个老年代的大小。

‌‌‌　　5. 6272K->6056K(237568K)，这三个数字分别对应GC之前占用堆内存的大小，GC之后堆内存占用，以及整个堆内存的大小。

‌‌‌　　6. 20516K->20516K(1069056K)，这三个数字分别对应GC之前占用元空间内存的大小，GC之后元空间内存占用，以及整个元空间内存的大小。

‌‌‌　　7. 0.0209707是该时间点GC总耗费时间。

‌‌‌　　从日志可以发现几次Full GC都是由于元空间不够导致的，可以将元空间调大点。

‌‌‌　　java -jar -Xloggc:./gc-adjust-%t.log -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+PrintGCDetails -XX:+PrintGCDateStamps  
‌‌‌　　-XX:+PrintGCTimeStamps -XX:+PrintGCCause  -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M 
‌‌‌　　microservice-eureka-server.jar

‌‌‌　　调整完再看下GC日志发现已经没有因为元空间不够导致的Full GC了。平常项目很大启动很慢可以考虑下元空间大小。

2.2.1. CMS和G1收集器的GC日志使用

‌‌‌　　对于CMS和G1垃圾收集器的FC日志有一点不一样，也可以试着打印下对应的GC日志分析下，可以发现GC日志里面的GC步骤跟前面分析的GC步骤是类似的。

‌‌‌　　1. 测试的程序

‌‌‌　　package com.liu.gclog;

‌‌‌　　import java.util.ArrayList;

‌‌‌　　public class HeapTest {

    byte[] a = new byte[1024 * 100];  //100KB

    public static void main(String[] args) throws InterruptedException {
        ArrayList<HeapTest> heapTests = new ArrayList<>();
        while (true) {
            heapTests.add(new HeapTest());
            Thread.sleep(10);
        }
    }
‌‌‌　　}

‌‌‌　　2. CMS的日志

‌‌‌　　-Xloggc:d:/gc-cms-%t.log -Xms50M -Xmx50M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+PrintGCDetails -XX:+PrintGCDateStamps  
 -XX:+PrintGCTimeStamps -XX:+PrintGCCause  -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M 
 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 

‌‌‌　　运行上面程序得到GC日志如下，可以看到CMS垃圾收集器运行过程中各阶段打印的日志。

‌‌‌‌‌‌　　3. G1日志

‌‌‌　　-Xloggc:d:/gc-g1-%t.log -Xms50M -Xmx50M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+PrintGCDetails -XX:+PrintGCDateStamps  
 -XX:+PrintGCTimeStamps -XX:+PrintGCCause  -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M -XX:+UseG1GC 

‌‌‌　　就不演示了。

2.2.2. GC日志可视化工具

‌‌‌　　上面的这些参数，能够帮查看分析GC的垃圾收集情况。但是如果GC日志很多很多，成千上万行。就算你一目十行，看完了，脑子也是一片空白。所以我们可以借助一些功能来帮助分析，这里推荐一个gceasy(https://gceasy.io)，可以上传gc文件，然后他会利用可视化的界面来展现GC情况。

‌‌‌　　具体下图所示

‌‌‌　　上图可以看到年轻代，老年代，以及永久代的内存分配，和最大使用情况。

　　图我们可以看到堆内存在GC之前和之后的变化，以及其他信息。
‌‌‌　　这个工具还提供基于机器学习的JVM智能优化建议，当然现在这个功能需要付费。

3. JVM参数汇总查看命令

‌‌‌　　1. java -XX:+PrintFlagsInitial 表示打印出所有参数选项的默认值。product后缀的的运行时候不能修改，manageable可以运行修改。

‌‌‌　　2. java -XX:+PrintFlagsFinal 表示打印出所有参数选项在运行程序时生效的值。

4. Class常量池与运行时常量池与字符串常量池

4.1. 分类

‌‌‌　　JVM中的常量池可以分成以下几类：

‌‌‌　　Class文件常量池。

‌‌‌　　全局字符串常量池。

‌‌‌　　运行时常量池。

4.2. Class常量池

‌‌‌　　Class常量池可以理解为是Class文件中的资源仓库。

‌‌‌　　Class文件中除了包含类的版本、字段、方法、接口等描述信息外。

‌‌‌　　还有一项信息就是常量池(constant pool table)，用于存放编译期生成的各种字面量(Literal)和符号引用(Symbolic References)。

‌‌‌　　常量池中主要存放两大类常量：字面量和符号引用。

‌‌‌　　通过javap命令反编译Class文件生成可以直接看的助计符指令。如

‌‌‌　　javap -v Math.class

‌‌‌　　红框标出的就是Class常量池信息。
‌‌‌　　

4.2.1. 字面量

‌‌‌　　字面量就是指由字母、数字等构成的字符串或者数值常量。

‌‌‌　　字面量只可以右值出现，所谓右值是指等号右边的值，如：int a=1 这里的a为左值，1为右值。在这个例子中1就是字面量。

‌‌‌　　int a = 1;
‌‌‌　　int b = 2;
‌‌‌　　int c = "abcdefg";
‌‌‌　　int d = "abcdefg";

4.2.2. 符号引用

‌‌‌　　符号引用是编译原理中的概念，是相对于直接引用来说的。主要包括了以下三类常量：

‌‌‌　　1. 类和接口的全限定名

‌‌‌　　2. 字段的名称和描述符

‌‌‌　　3. 方法的名称和描述符

‌‌‌　　上面的a，b就是字段名称，就是一种符号引用

‌‌‌　　Math类常量池里的 Lcom/tuling/jvm/Math 是类的全限定名。

‌‌‌　　main和compute是方法名称。

‌‌‌　　()是一种UTF8格式的描述符。

‌‌‌　　这些都是符号引用。

4.3. 运行时常量池

‌‌‌　　Class的常量池是静态信息也被称为静态常量池，该常量池数据一旦被装入内存就变成运行时常量池(C++对象实现)。

‌‌‌　　运行时常量池大部分数据保存的是，从Class文件常量池（静态常量池）加载的字面量和符合引用的数据。字符串常量池，也可以理解成运行时常量池分出来的一部分，JDK1.7开始被分离出来。

‌‌‌　　运行时常量池中有两种类型，分别是符号引用和静态常量。

‌‌‌　　符号引用，在程序加载类时候，转变为直接引用，记录被加载到内存区域的代码的地址（静态链接过程，静态链接存在方法区的运行时常量池。）或者运行时会转变为被加载到内存区域的代码的直接引用（动态链接过程，动态链接存储在每个方法栈帧中）。

‌‌‌　　静态常量，主要分为字符串常量和数字常量。字符串常量保存是字符串常量池对应字符串的引用。静态常量的数据主要是从加载Class的常量池字面量构建的。

‌‌‌　　注意

‌‌‌　　1. 代码中运行new String创建对象，或者调用字符串的intern方法等，都有可能将字符串的引用加到运行时常量池，所以运行时的常量池数据不只是来源Class的常量池。

4.4. 字符串常量池

‌‌‌　　字符串常量池，也可以理解成运行时常量池分出来的一部分，JDK1.7开始被分离出来。

4.4.1. 字符串常量池的设计思想

‌‌‌　　1. 字符串的分配，和其他的对象分配一样，耗费高昂的时间与空间代价，作为最基础的数据类型，大量频繁的创建字符串，极大程度地影响程序的性能。

‌‌‌　　2. JVM为了提高性能和减少内存开销，在实例化字符串常量的时候进行了一些优化。

‌‌‌　　为字符串开辟一个字符串常量池，类似于缓存区。

‌‌‌　　创建字符串常量时，首先查询字符串常量池是否存在该字符串。

‌‌‌　　存在该字符串，返回引用实例，不存在，实例化该字符串并把引入放入池中。

4.4.2. 字符串常量池位置

‌‌‌　　首先永久代和元空间都是方法区的实现。

‌‌‌　　Jdk1.6及之前： 有永久代，运行时常量池在永久代，运行时常量池包含字符串常量池。

‌‌‌　　Jdk1.7：有永久代，但已经逐步去永久代，字符串常量池从永久代里的运行时常量池分离到堆里。

‌‌‌　　Jdk1.8及之后： 无永久代，运行时常量池在元空间，字符串常量池里依然在堆里。

‌‌‌　　用一个程序证明下字符串常量池在哪里：

‌‌‌　　package com.liu.zi_fu_chuang_chang_liang_chi;

‌‌‌　　import java.util.ArrayList;

‌‌‌　　/**
 * @author jsLiu
 * @version 1.0.0
 * @description 查看字符串常量池在哪里例子
 * jdk6：-Xms6M -Xmx6M -XX:PermSize=6M -XX:MaxPermSize=6M
 * jdk8：-Xms6M -Xmx6M -XX:MetaspaceSize=6M -XX:MaxMetaspaceSize=6M
 * @date 2023/10/08
 */
‌‌‌　　public class Test1 {
    public static void main(String[] args) {
        ArrayList<String> list = new ArrayList<String>();
        for (int i = 0; i < 10000000; i++) {
            String str = String.valueOf(i).intern();
            list.add(str);
        }
    }
‌‌‌　　}
‌‌‌　　//运行结果：
‌‌‌　　//        jdk7及以上：Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
‌‌‌　　//        jdk6：Exception in thread "main" java.lang.OutOfMemoryError: PermGen space

‌‌‌　　不理解就看String的intern()方法章节就能明白。

4.4.3. 字符串常量池设计原理

‌‌‌　　字符串常量池底层是hotspot的C++实现的，底层类似一个 HashTable(数组加链表)，对应实现就是StringTable， 链表中保存的**元素本质上就是一个个字符串对象的引用。

‌‌‌　　字符串常量池存放数据是这样的，将字符串对象引用添加到StringTable中一个桶下的链表中。‌‌然后将字符串对象存放到堆中（JDK1.7）或者方法区（JDK1.6）。
‌‌‌　　存储字符串对象位置是通过key定位的，(key是字符串字面量和长度组成）。通过key计算hash值找到数组的下标的链表，然后将字符串对象引用存放到链表中。

‌‌‌　　查找字符串就是通过key定位到存储位置，(key是字符串字面量和长度组成）。通过key计算hash值找到数组的下标的链表。然后通过字符串字面量比对链表中的元素。找到对相同字面量的字符串对象引用返回。

‌‌‌　　Hotspot虚拟机下字符串常量池实现部分源码如下

4.4.4. String的intern()方法

‌‌‌　　看一道比较常见的面试题，下面的代码创建了多少个 String 对象。

‌‌‌　　首先s1先在字符串常量池所属区域（JDK1.6在方法区，JDK1.7及以上在堆）创建"he"和"llo"字符串对象，然后把这两个引用放到StringTable中。接下来在堆中又创建三个新的"he"和"llo"和"hello"字符串对象，共计五个。

‌‌‌　　s2时候运行intern()方法，这种情况下JDK1.6会创建1个新的字符串对象，JDK1.7及以上不会创建新对象。具体情况看下面分析。

‌‌‌　　String s1 = new String("he") + new String("llo");
‌‌‌　　String s2 = s1.intern();
 
‌‌‌　　System.out.println(s1 == s2);
‌‌‌　　// 在 JDK 1.6 下输出是 false，创建了 6 个对象
‌‌‌　　// 在 JDK 1.7 及以上的版本输出是 true，创建了 5 个对象
‌‌‌　　// 当然我们这里没有考虑GC，但这些对象确实存在或存在过

‌‌‌　　注意

‌‌‌　　字符串常量池存的是字符串对象的引用。

‌‌‌　　1. 在 JDK 1.6 中，调用 intern() 首先会在字符串常量池中寻找 equal() 相等的字符串，假如字符串存在，就返回字符串常量池中的对象引用。

‌‌‌　　假如字符串不存在，创建intern字面量相同的字符串对象到字符串常量池，以key计算得到下标值和value(常量池字符串对象引用)添加到StringTable中，并返回引用。

　‌‌‌　　2. 在 JDK 1.7 (及以上版本)中，由于字符串池不在永久代了，intern() 做了一些修改，更方便地利用堆中的对象。

‌‌‌　　调用 intern() 首先会在字符串常量池StringTable中寻找 equal() 相等的字符串，假如字符串存在，就返回StringTable中对象的引用。

‌‌‌　　不存在的情况下，堆上有对应字符串对象，就复制它的引用存放到字符串常量池，以key计算得到下标值将value(字符串对象的引用)元素方式添加到StringTable中。

‌‌‌　　堆上不存在，就先创建该字符串对象到堆中，以key计算得到下标值和value(字符串对象的引用)元素方式添加到StringTable中。

由上面两个图，也不难理解为什么 JDK 1.6 字符串池溢出会抛出 OutOfMemoryError: PermGen space ，而在 JDK 1.7 及以上版本抛出 OutOfMemoryError: Java heap space 。一个存储在方法区，一个存储在堆上。

4.4.5. 关于String是不可变

‌‌‌　　来看一下String类的源码。

‌‌‌　　从源码中我们可以看出，首先String类是final的，说明其不可被继承，就不会被子类改变其不可变的特性；其次，String的底层其实是一个被final修饰的数组，说明这个value在确定值后就不能指向一个新的数组。这里我们要明确一点，被final修饰的数组虽然不能指向一个新的数组，但却是可以修改数组的值的：
　　

‌‌‌　　既然可以被修改，那String怎么是不可变的呢？因为String类并没有提供任何一个方法去修改数组的值，所以String的不可变性是由于其底层的实现，而不是一个final。

4.4.6. 字符串操作分析案例

‌‌‌　　例1.

‌‌‌　　String s = "zhuge";  // s指向常量池中的引用

‌‌‌　　这种方式创建的字符串对象，只会在常量池中。

‌‌‌　　先用"zhuge"这个字面量去常量池StringTable中通过 equals(key) 方法，判断是否有相同字面量的对象。

‌‌‌　　如果有，则直接返回该对象在常量池StringTable中的引用。

‌‌‌　　如果没有，则会在常量池所属区域（JDK1.6在方法区，JDK1.7及以上在堆）创建一个新对象，将其引用存放到常量池StringTable中，再返回常量池StringTable中的引用。

‌‌‌‌‌‌　　例2.

‌‌‌　　String s1 = new String("zhuge");  // s1指向内存中的对象引用

‌‌‌‌‌‌　　先用"zhuge"这个字面量去常量池StringTable中通过 equals(key) 方法，判断是否有相同字面量的对象。如果没有，则会在常量池所属区域（JDK1.6在方法区，JDK1.7及以上在堆）创建一个新对象，将其引用存放到常量池StringTable中。

‌‌‌　　然后在堆中创建一个新的字符串对象"zhuge"，并将引用返回给s1。

‌‌‌　　例3.

‌‌‌　　s0和s1中的”zhuge”在编译期就被确定了，会从Class静态常量池加载到字符串常量池。
可以理解为创建zhuge”字符串对象，引用存放到字符串常量池。所以s0=s1为true。

‌‌‌　　”zhu”和”ge”都是字符串常量，当一个字符串由多个字符串常量连接而成时，它自己肯定也是字符串常量。s2在编译期就被优化为一个字符串常量"zhuge"，所以s2也是字符串常量池中”zhuge”的引用。

‌‌‌　　String s0="zhuge";
‌‌‌　　String s1="zhuge";
‌‌‌　　String s2="zhu" + "ge";
‌‌‌　　System.out.println( s0==s1 ); //true
‌‌‌　　System.out.println( s0==s2 ); //true

‌‌‌　　例4.

‌‌‌　　s0的”zhuge”在编译期就被确定了，会从Class静态常量池加载到字符串常量池。可以理解为创建zhuge”字符串对象，引用存放到字符串常量池，并把引用给s0。

‌‌‌　　s1用new String() 创建的字符串不是常量，不能在编译期就确定，会在运行时候会在堆中新创建”zhuge”对象，引用返回给s1。

‌‌‌　　s2后半部分 new String(”ge”)所以也无法在编译期确定，会在运行时候在堆中新创建”zhuge”对象，引用返回给s2。

‌‌‌　　String s0="zhuge";
‌‌‌　　String s1=new String("zhuge");
‌‌‌　　String s2="zhu" + new String("ge");
‌‌‌　　System.out.println( s0==s1 );　　// false
‌‌‌　　System.out.println( s0==s2 )；　 // false
‌‌‌　　System.out.println( s1==s2 );　　// false

‌‌‌　　例5.

‌‌‌‌‌‌　　JVM对于字符串常量的"+“号连接，将在程序编译期，JVM就将常量字符串的”+"连接优化为连接后的值。

‌‌‌　　拿"a" + 1来说，经编译器优化后在Class静态常量池中就也是a1，返回引用就是字符串常量池中的a1字符串对象的引用，故下面程序最终的结果都为true。

  String a = "a1";
  String b = "a" + 1;
  System.out.println(a == b); // true 
  
  String a = "atrue";
  String b = "a" + "true";
  System.out.println(a == b); // true 
  
  String a = "a3.4";
  String b = "a" + 3.4;
  System.out.println(a == b); // true

‌‌‌　　例6.

‌‌‌　　JVM对于字符串的"+“连接中，有字符串引用存在，而引用的值在程序编译期是无法确定的。即"a" + bb无法被编译器优化，只能在程序运行期来动态分配并将连接后的新地址赋给b，即b引用是堆中新创建字符串对象“ab”。所以下面程序的结果为false。

‌‌‌　　String a = "ab";
‌‌‌　　String bb = "b";
‌‌‌　　String b = "a" + bb;

‌‌‌　　System.out.println(a == b); // false

‌
‌‌‌　　例7.

‌‌‌　　bb字符串加了final修饰，对于final修饰的变量，它在编译时被解析为常量值的一个本地拷贝存储到自己的常量池中或嵌入到它的字节码流中。所以此时的"a" + bb和"a" + "b"效果是一样的。故下面程序的结果为true。

‌‌‌　　String a = "ab";
‌‌‌　　final String bb = "b";
‌‌‌　　String b = "a" + bb;

‌‌‌　　System.out.println(a == b); // true

‌‌‌　　例8.
　　
‌‌‌　　JVM对于字符串引用的bb，虽然是final修饰，它的值在编译期无法确定。只有在程序运行期调用方法后，将方法的返回值和"a"来动态连接并分配地址为b，即在堆中新创建"ab"对象返回引用给b，故下面程序的结果为false。

‌‌‌　　String a = "ab";
‌‌‌　　final String bb = getBB();
‌‌‌　　String b = "a" + bb;

‌‌‌　　System.out.println(a == b); // false

‌‌‌　　private static String getBB() 
‌‌‌　　{  
    return "b";  
 }

‌‌‌　　例9.
　　
‌‌‌　　JVM对于字符串引用的bb，虽然是final修饰，它的值在编译期无法确定。只有在程序运行期调用方法后，将方法的返回值和"a"来动态连接并分配地址为b，即在堆中新创建”ab“对象返回引用给b，故下面程序的结果为false。

‌‌‌　　String a = "ab";
‌‌‌　　final String bb = getBB();
‌‌‌　　String b = "a" + bb;

‌‌‌　　System.out.println(a == b); // false

‌‌‌　　private static String getBB() 
‌‌‌　　{  
    return "b";  
 }

‌‌‌　　例10.

‌‌‌　　1. 运行时候先在字符串常量池所属区域（JDK1.6在方法区，JDK1.7及以上在堆）创建"计算机"和"技术" 两个字符串对象并存入常量池StringTable中，然后在堆中创建“计算机技术"字符串 对象返回引用给str2。

‌‌‌　　2. 堆内存中还有个StringBuilder的对象，用完会GC回收，StringBuilder的toString方法会new String()创建字符串对象就是堆中的"计算机技术" 对象。

‌‌‌　　3. 因为str2.intern()时候，字符串常量池里头没有“计算机技术" 对象。

‌‌‌　　JDK1.7及以上会引用堆中的"计算机技术" 对象，str2 == str2.intern()是true。

‌‌‌　　JDK1.6则会自己新创建"计算机技术" 对象在方法区并引用，str2 == str2.intern()是false。

‌‌‌　　String str2 = new StringBuilder("计算机").append("技术").toString();   


‌‌‌　　System.out.println(str2 == str2.intern());  //JDK1.7 true JDK1.6 false

‌‌‌　　例11.

‌‌‌　　1. 运行时候先在字符串常量池所属区域（JDK1.6在方法区，JDK1.7及以上在堆）创建"ja"和"va" 两个字符串对象并存入常量池StringTable中，然后在堆中创建“java" 对象，返回引用给str1 。

‌‌‌　　2. 堆内存中还有个StringBuilder的对象，用完会GC回收，StringBuilder的toString方法会new String()创建就是堆中的"java" 对象。

‌‌‌　　3. java是关键字，在JVM初始化的相关类里肯定早就创建，并将引用放进字符串常量池了，所以不管JDK1.6还是JDK1.7下 str1 == str1.intern()是false。

‌‌‌　　String str1 = new StringBuilder("ja").append("va").toString();    
‌‌‌　　System.out.println(str1 == str1.intern());   //false

‌‌‌　　例12.

‌‌‌　　1. 运行时候先在字符串常量池所属区域（JDK1.6在方法区，JDK1.7及以上在堆）创建"abc" 字符串对象并将引用存入常量池StringTable中，然后在堆中创建“abc" 对象，返回引用给s3 。

‌‌‌　　2. 堆内存中还有个StringBuilder的对象，用完会GC回收，StringBuilder的toString方法会new String()创建就是堆中的"abc" 对象。

‌‌‌　　3. 因为str3.intern()时候，字符串常量池里头已存在“abc" 对象的引用，不管JDK1.6还是JDK1.7下str3 == str3.intern()是false。

‌‌‌　　String s3=new StringBuilder("abc").toString();
‌‌‌　　System.out.println(s3==s3.intern());  //false

5. 八种基本类型的包装类和对象池

‌‌‌　‌‌‌　　JAVA中基本类型的包装类的大部分都实现了常量池技术(严格来说应该叫对象池，在堆上)，这些类是Byte,Short,Integer,Long,Character,Boolean,另外两种浮点数类型的包装类则没有实现。
‌‌‌　　另外Byte,Short,Integer,Long,Character这5种整型的包装类也只是在对应值小于等于127时才可使用对象池，也即对象不负责创建和管理大于127的这些类的对象。
‌‌‌　　因为一般这种比较小的数用到的概率相对较大。

‌‌‌　　看下例子就懂了

‌‌‌　　public class Test {

    public static void main(String[] args) {
        //5种整形的包装类Byte,Short,Integer,Long,Character的对象，  
        //在值小于127时可以使用对象池  
        Integer i1 = 127;  //这种调用底层实际是执行的Integer.valueOf(127)，里面用到了IntegerCache对象池
        Integer i2 = 127;
        System.out.println(i1 == i2);//输出true  

        //值大于127时，不会从对象池中取对象  
        Integer i3 = 128;
        Integer i4 = 128;
        System.out.println(i3 == i4);//输出false  
        
        //用new关键词新生成对象不会使用对象池
        Integer i5 = new Integer(127);  
        Integer i6 = new Integer(127);
        System.out.println(i5 == i6);//输出false 

        //Boolean类也实现了对象池技术  
        Boolean bool1 = true;
        Boolean bool2 = true;
        System.out.println(bool1 == bool2);//输出true  

        //浮点类型的包装类没有实现对象池技术  
        Double d1 = 1.0;
        Double d2 = 1.0;
        System.out.println(d1 == d2);//输出false  
    }
‌‌‌　　} 

‌‌‌