执行引擎位置：
执行引擎属于JVM的下层，里面包括：解释器、即时编译器、垃圾回收器执行引擎概述：
执行引擎是Java虚拟机核心的组成部分之一。“虚拟机”是一个相对于“物理机”的概念，这两种机器都有代码执行能力，其区别是物理机的执行引擎是直接建立在处理器、缓存、指令集和操作系统层面上的，而虚拟机的执行引擎则是由软件自行实现的，因此可以不受物理条件制约地定制指令集与执行引擎的结构体系，能够执行那些不被硬件直接支持的指令集格式。JVM的主要任务是负责装载字节码到其内部，但字节码并不能够直接运行在操作系统之上，因为字节码指令并非等价于本地机器指令，它内部包含的仅仅只是一些能够被JVM所识别的字节码指令、符号表，以及其他辅助信息。那么，如果想要让一个Java程序运行起来，执行引擎（Execution Engine）的任务就是将字节码指令解释/编译为对应平台上的本地机器指令才可以。简单来说，JVM中的执行引擎充当了将高级语言翻译为机器语言的译者。执行引擎工作过程：
执行引擎在执行的过程中究竟需要执行什么样的字节码指令完全依赖于PC寄存器。每当执行完一项指令操作后，PC寄存器就会更新下一条需要被执行的指令地址。当然方法在执行的过程中，执行引擎有可能会通过存储在局部变量表中的对象引用准确定位到存储在Java堆区中的对象实例信息，以及通过对象头中的元数据指针定位到目标对象的类型信息。从外观上来看，所有的Java虚拟机的执行引擎输入、处理、输出都是一致的：输入的是字节码二进制流，处理过程是字节码解析执行、即时编译的等效过程，输出的是执行过程。Java 代码的解释执行和即时编译：
大部分的程序代码转换成物理机的目标代码或虚拟机能执行的指令集之前，都需要经过下图中的各个步骤：前面橙色部分是编译生成生成字节码文件的过程（javac 指令），和JVM无关后面绿色（解释执行）和蓝色（即时编译）才是JVM需要考虑的过程Java代码编译是由Java源码编译器来完成，流程图如下所示：Java字节码的执行是由JVM执行引擎来完成，流程图如下所示我们用一个总的图，来总结解释器和编译器什么是解释器？什么是JIT编译器？
解释器（Interpreter）：当Java虚拟机启动时会根据预定义的规范对字节码采用逐行解释的方式执行，将每条字节码文件中的内容“翻译”为对应平台的本地机器指令执行。JIT（Just In Time Compiler）编译器：就是虚拟机将源代码直接编译成和本地机器平台相关的机器语言。为什么Java是半编译半解释型语言？
JDK1.0时代，将Java语言定位为“解释执行”还是比较准确的。再后来，Java也发展出可以直接生成本地代码的编译器。
现在JVM在执行Java代码的时候，通常都会将解释执行与编译执行二者结合起来进行。
将字节码翻译成本地代码后，就可以做一个缓存操作，存储在方法区的JIT 代码缓存中
机器码：
各种用二进制编码方式表示的指令，叫做机器指令码。开始，人们就用它采编写程序，这就是机器语言。机器语言虽然能够被计算机理解和接受，但和人们的语言差别太大，不易被人们理解和记忆，并且用它编程容易出差错。用它编写的程序一经输入计算机，CPU直接读取运行，因此和其他语言编的程序相比，执行速度最快。机器指令与CPU紧密相关，所以不同种类的CPU所对应的机器指令也就不同。指令：
由于机器码是由0和1组成的二进制序列，可读性实在太差，于是人们发明了指令。指令就是把机器码中特定的0和1序列，简化成对应的指令（一般为英文简写，如mov，inc等），可读性稍好由于不同的硬件平台，执行同一个操作，对应的机器码可能不同，所以不同的硬件平台的同一种指令（比如mov），对应的机器码也可能不同。指令集：
不同的硬件平台，各自支持的指令，是有差别的。因此每个平台所支持的指令，称之为对应平台的指令集。如常见的x86指令集，对应的是x86架构的平台ARM指令集，对应的是ARM架构的平台汇编语言：
由于指令的可读性还是太差，于是人们又发明了汇编语言。在汇编语言中，用助记符（Mnemonics）代替机器指令的操作码，用地址符（Symbol）或标号（Label）代替指令或操作数的地址。在不同的硬件平台，汇编语言对应着不同的机器语言指令集，通过汇编过程转换成机器指令。由于计算机只认识指令码，所以用汇编语言编写的程序还必须翻译（汇编）成机器指令码，计算机才能识别和执行。高级语言：
为了使计算机用户编程序更容易些，后来就出现了各种高级计算机语言。高级语言比机器语言、汇编语言更接近人的语言当计算机执行高级语言编写的程序时，仍然需要把程序解释和编译成机器的指令码。完成这个过程的程序就叫做解释程序或编译程序。高级语言也不是直接翻译成 机器指令 ①首先需要通过编译阶段，将高级语言翻译为为汇编语言 ②再通过汇编阶段，将生成的汇编语言翻译成机器指令 ③如下面说的C和C++C、C++源程序执行过程：
编译过程又可以分成两个阶段：编译和汇编。编译过程：是读取源程序（字符流），对之进行词法和语法的分析，将高级语言指令转换为功能等效的汇编代码汇编过程：实际上指把汇编语言代码翻译成目标机器指令的过程。字节码：
字节码是一种中间状态（中间码）的二进制代码（文件），它比机器码更抽象，需要直译器转译后才能成为机器码字节码主要为了实现特定软件运行和软件环境、与硬件环境无关。字节码的实现方式是通过编译器和虚拟机器。编译器将源码编译成字节码，特定平台上的虚拟机器将字节码转译为可以直接执行的指令。字节码典型的应用为：Java bytecode为什么要有解释器？
JVM设计者们的初衷仅仅只是单纯地为了满足Java程序实现跨平台特性，因此避免采用静态编译的方式直接生成本地机器指令，从而诞生了实现解释器在运行时采用逐行解释字节码执行程序的想法。解释器真正意义上所承担的角色就是一个运行时“翻译者”，将字节码文件中的内容“翻译”为对应平台的本地机器指令执行。当一条字节码指令被解释执行完成后，接着再根据PC寄存器中记录的下一条需要被执行的字节码指令执行解释操作。解释器的分类：
在Java的发展历史里，一共有两套解释执行器，即古老的字节码解释器、现在普遍使用的模板解释器。 ①字节码解释器在执行时通过纯软件代码模拟字节码的执行，效率非常低下。 ②而模板解释器将每一条字节码和一个模板函数相关联，模板函数中直接产生这条字节码执行时的机器码，从而很大程度上提高了解释器的性能。
在HotSpot VM中，解释器主要由Interpreter模块和Code模块构成。 ① Interpreter模块：实现了解释器的核心功能 ②Code模块：用于管理HotSpot VM在运行时生成的本地机器指令
解释器的现状：
由于解释器在设计和实现上非常简单，因此除了Java语言之外，还有许多高级语言同样也是基于解释器执行的，比如Python、Perl、Ruby等。但是在今天，基于解释器执行已经沦落为低效的代名词，并且时常被一些C/C++程序员所调侃。为了解决这个问题，JVM平台支持一种叫作即时编译的技术。即时编译的目的是避免函数被解释执行，而是将整个函数体编译成为机器码，每次函数执行时，只执行编译后的机器码即可，这种方式可以使执行效率大幅度提升。不过无论如何，基于解释器的执行模式仍然为中间语言的发展做出了不可磨灭的贡献。Java 代码执行的分类：
第一种是将源代码编译成字节码文件，然后在运行时通过解释器将字节码文件转为机器码执行第二种是编译执行（直接编译成机器码）。现代虚拟机为了提高执行效率，会使用即时编译技术（JIT，Just In Time）将方法编译成机器码后再执行Hotspot 同时采用解释器和即时编译器：
HotSpot VM是目前市面上高性能虚拟机的代表作之一。它采用解释器与即时编译器并存的架构。
在Java虚拟机运行时，解释器和即时编译器能够相互协作，各自取长补短，尽力去选择最合适的方式来权衡编译本地代码的时间和直接解释执行代码的时间。
在今天，Java程序的运行性能早已脱胎换骨，已经达到了可以和C/C++ 程序一较高下的地步。
为啥我们还需要解释器呢？
有些开发人员会感觉到诧异，既然HotSpotVM中已经内置JIT编译器了，那么为什么还需要再使用解释器来“拖累”程序的执行性能呢？比如JRockit VM内部就不包含解释器，字节码全部都依靠即时编译器编译后执行。JRockit虚拟机是砍掉了解释器，也就是只采及时编译器。那是因为呢JRockit只部署在服务器上，一般已经有时间让他进行指令编译的过程了，对于响应来说要求不高，等及时编译器的编译完成后，就会提供更好的性能。首先明确两点： ①当程序启动后，解释器可以马上发挥作用，响应速度快，省去编译的时间，立即执行。 ②编译器要想发挥作用，把代码编译成本地代码，需要一定的执行时间，但编译为本地代码后，执行效率高。结论：
尽管JRockit VM中程序的执行性能会非常高效，但程序在启动时必然需要花费更长的时间来进行编译。对于服务端应用来说，启动时间并非是关注重点，但对于那些看中启动时间的应用场景而言，或许就需要采用解释器与即时编译器并存的架构来换取一个平衡点。当解释器与即时编译器共存，在Java虚拟器启动时，解释器可以首先发挥作用，而不必等待即时编译器全部编译完成后再执行，这样可以省去许多不必要的编译时间。随着时间的推移，编译器发挥作用，把越来越多的代码编译成本地代码，获得更高的执行效率。同时，解释执行在编译器进行激进优化不成立的时候，作为编译器的“逃生门”。Hotspot JVM 代码执行方式：
当虚拟机启动的时候，解释器可以首先发挥作用，而不必等待即时编译器全部编译完成再执行，这样可以省去许多不必要的编译时间。
随着程序运行时间的推移，即时编译器逐渐发挥作用，根据热点探测功能，将有价值的字节码编译为本地机器指令，以换取更高的程序执行效率。
注意解释执行与编译执行在线上环境微妙的辩证关系。机器在热机状态可以承受的负载要大于冷机状态。如果以热机状态时的流量进行切流，可能使处于冷机状态的服务器因无法承载流量而假死。
注意：服务器不停工作称热 ，服务器停止工作或工作缓慢称冷。
在生产环境发布过程中，以分批的方式进行发布，根据机器数量划分成多个批次，每个批次的机器数至多占到整个集群的1/8。曾经有这样的故障案例：某程序员在发布平台进行分批发布，在输入发布总批数时，误填写成分为两批发布。如果是热机状态，在正常情况下一半的机器可以勉强承载流量，但由于刚启动的JVM均是解释执行，还没有进行热点代码统计和JIT动态编译，导致机器启动之后，当前1/2发布成功的服务器马上全部宕机，此故障说明了JIT的存在。—阿里团队
编译器相关概念解释：
Java 语言的“编译期”其实是一段“不确定”的操作过程
因为它可能是指一个前端编译器（其实叫“编译器的前端”更准确一些）把.java文件转变成.class文件的过程
也可能是指虚拟机的后端运行期编译器（JIT编译器，Just In Time Compiler）把字节码转变成机器码的过程。
还可能是指使用静态提前编译器（AOT编译器，Ahead of Time Compiler）直接把.java文件编译成本地机器代码的过程。
典型的编译器：
前端编译器：Sun的javac、Eclipse JDT中的增量式编译器（ECJ）。JIT编译器：HotSpot VM的C1、C2编译器。AOT 编译器：GNU Compiler for the Java（GCJ）、Excelsior JET。热点代码：
当然是否需要启动JIT编译器将字节码直接编译为对应平台的本地机器指令，则需要根据代码被调用执行的频率而定。关于那些需要被编译为本地代码的字节码，也被称之为“热点代码”，JIT编译器在运行时会针对那些频繁被调用的“热点代码”做出深度优化，将其直接编译为对应平台的本地机器指令，以此提升Java程序的执行性能。一个方法究竟要被调用多少次，或者一个循环体究竟需要执行多少次循环才可以达到这个标准？必然需要一个明确的阈值，JIT编译器才会将这些“热点代码”编译为本地机器指令执行。这里主要依靠热点探测功能。热点探测技术：
目前HotSpot VM所采用的热点探测方式是基于计数器的热点探测。采用基于计数器的热点探测，HotSpot VM将会为每一个方法都建立2个不同类型的计数器，分别为方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）。 ①方法调用计数器用于统计方法的调用次数 ②回边计数器则用于统计循环体执行的循环次数方法调用计数器：
这个计数器就用于统计方法被调用的次数，它的默认阀值在Client模式下是1500次，在Server模式下是10000次。超过这个阈值，就会触发JIT编译。这个阀值可以通过虚拟机参数 -XX:CompileThreshold 来人为设定。当一个方法被调用时，会先检查该方法是否存在被JIT编译过的版本。 ①如果存在，则优先使用编译后的本地代码来执行 ②如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阀值。 1、如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。 2、如果未超过阈值，则使用解释器对字节码文件解释执行热度衰减：
如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter Decay），而这段时间就称为此方法统计的半衰周期（Counter Half Life Time）半衰周期是化学中的概念，比如出土的文物通过查看C60来获得文物的年龄JVM 进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数 -XX:-UseCounterDecay 来关闭热度衰减如果让方法计数器统计方法调用的绝对次数，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。另外，可以使用-XX:CounterHalfLifeTime参数设置半衰周期的时间，单位是秒。回边计数器：
它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”（Back Edge）。显然，建立回边计数器统计的目的就是为了触发OSR编译。HotSpotVM 可以设置程序执行方法：
缺省情况下HotSpot VM是采用解释器与即时编译器并存的架构，当然开发人员可以根据具体的应用场景，通过命令显式地为Java虚拟机指定在运行时到底是完全采用解释器执行，还是完全采用即时编译器执行。如下所示： ①-Xint：完全采用解释器模式执行程序； ②-Xcomp：完全采用即时编译器模式执行程序。如果即时编译出现问题，解释器会介入执行 ③-Xmixed：采用解释器+即时编译器的混合模式共同执行程序。HotSpotVM中 JIT 分类：
JIT的编译器还分为了两种，分别是C1和C2，在HotSpot VM中内嵌有两个JIT编译器，分别为Client Compiler和Server Compiler，但大多数情况下我们简称为C1编译器 和C2编译器。开发人员可以通过如下命令显式指定Java虚拟机在运行时到底使用哪一种即时编译器，如下所示： ①-client：指定Java虚拟机运行在Client模式下，并使用C1编译器； C1编译器会对字节码进行简单和可靠的优化，耗时短，以达到更快的编译速度。 ②-server：指定Java虚拟机运行在server模式下，并使用C2编译器。 C2进行耗时较长的优化，以及激进优化，但优化的代码执行效率更高。（使用C++）C1 和 C2编译器不同的优化策略：
在不同的编译器上有不同的优化策略，C1编译器上主要有方法内联，去虚拟化、元余消除。 ①方法内联：将引用的函数代码编译到引用点处，这样可以减少栈帧的生成，减少参数传递以及跳转过程 ②去虚拟化：对唯一的实现樊进行内联 ③冗余消除：在运行期间把一些不会执行的代码折叠掉
C2的优化主要是在全局层面，逃逸分析是优化的基础。基于逃逸分析在C2上有如下几种优化： ①标量替换：用标量值代替聚合对象的属性值 ②栈上分配：对于未逃逸的对象分配对象在栈而不是堆 ③同步消除：清除同步操作，通常指synchronized
分层编译策略：
分层编译（Tiered Compilation）策略：程序解释执行（不开启性能监控）可以触发C1编译，将字节码编译成机器码，可以进行简单优化，也可以加上性能监控，C2编译会根据性能监控信息进行激进优化。不过在Java7版本之后，一旦开发人员在程序中显式指定命令“-server"时，默认将会开启分层编译策略，由C1编译器和C2编译器相互协作共同来执行编译任务。即时编译器的性能总结：
一般来讲，JIT编译出来的机器码性能比解释器解释执行的性能高C2编译器启动时长比C1慢，系统稳定执行以后，C2编译器执行速度远快于C1编译器Graal 编译器：
自JDK10起，HotSpot又加入了一个全新的及时编译器：Graal编译器编译效果短短几年时间就追平了G2编译器，未来可期目前，带着实验状态标签，需要使用开关参数去激活才能使用 -XX:+UnlockExperimentalvMOptions -XX:+UseJVMCICompilerAOT 编译器：
jdk9引入了AoT编译器（静态提前编译器，Ahead of Time Compiler）
Java9引入了实验性AOT编译工具jaotc。它借助了Graal编译器，将所输入的Java类文件转换为机器码，并存放至生成的动态共享库之中。
所谓AOT编译，是与即时编译相对立的一个概念。 ①我们知道，即时编译指的是在程序的运行过程中，将字节码转换为可在硬件上直接运行的机器码，并部署至托管环境中的过程。 ②而AOT编译指的则是，在程序运行之前，便将字节码转换为机器码的过程。
AOT编译器编译器的优缺点：
最大的好处： ①Java虚拟机加载已经预编译成二进制库，可以直接执行。 ②不必等待即时编译器的预热，减少Java应用给人带来“第一次运行慢” 的不良体验缺点： ①破坏了 java “ 一次编译，到处运行”，必须为每个不同的硬件，OS编译对应的发行包 ②降低了Java链接过程的动态性，加载的代码在编译器就必须全部已知。 ③还需要继续优化中，最初只支持Linux X64 java base深入理解Java中的String String 的概述：
String：字符串，使用一对 “” 引起来表示 String s1 = "mogublog" ; // 字面量的定义方式 String s2 = new String("moxi"); // new 对象的方式 String声明为final的，不可被继承String实现了Serializable接口：表示字符串是支持序列化的。实现了Comparable接口：表示String可以比较大小string在jdk8及以前内部定义了final char[] value用于存储字符串数据。JDK9时改为byte[]为什么改为 byte[] 存储？
String类的当前实现将字符存储在char数组中，每个字符使用两个字节(16位)。
从许多不同的应用程序收集的数据表明，字符串是堆使用的主要组成部分，而且大多数字符串对象只包含拉丁字符。这些字符只需要一个字节的存储空间，因此这些字符串对象的内部char数组中有一半的空间将不会使用。
之前 String 类使用 UTF-16 的 char[] 数组存储，现在改为 byte[] 数组 外加一个编码标志位存储，该编码标志将指定 String 类中 byte[] 数组的编码方式
结论：String再也不用char[] 来存储了，改成了byte [] 加上编码标记，节约了一些空间
同时基于String的数据结构，例如StringBuffer和StringBuilder也同样做了修改
String 的基本特征：
String：代表不可变的字符序列。简称：不可变性。
当对字符串重新赋值时，需要重写指定内存区域赋值，不能使用原有的value进行赋值。
当对现有的字符串进行连接操作时，也需要重新指定内存区域赋值，不能使用原有的value进行赋值。
当调用String的replace()方法修改指定字符或字符串时，也需要重新指定内存区域赋值，不能使用原有的value进行赋值。
通过字面量的方式（区别于new）给一个字符串赋值，此时的字符串值声明在字符串常量池中。
经典例题分析：
public class StringExer { String str = new String("good"); char[] ch = {'t', 'e', 's', 't'}; public void change(String str, char ch[]) { str = "test ok"; ch[0] = 'b'; } public static void main(String[] args) { StringExer ex = new StringExer(); ex.change(ex.str, ex.ch); System.out.println(ex.str);//good System.out.println(ex.ch);//best } } java在方法传递参数时，是将变量复制一份，然后传入方法体去执行。基本类型的传递： ①虚拟机分配给num一个内存地址，并且存了一个值0. ②虚拟机复制了一个num，我们叫他numCopy，numCopy和num的内存地址不同，但存的值都是0。 ③虚拟机将numCopy传入方法，方法将numCopy的值改为1. ④方法结束，方法外打印num的值，由于num内存中的值没有改变，还是0，所以打印是0.封装类型的传递： ①虚拟机在堆中开辟了一个Product的内存空间，内存中包含proName和num。 ②虚拟机在栈中分配给p一个内存地址，这个地址中存的是①中的Product的内存地址。 ③虚拟机复制了一个p，我们叫他pCopy,p和pCopy的内存地址不同，但它们存的值是相同的，都是①中Product的内存地址。 ④将pCopy传入方法，方法改变了①中的proName和num。 ⑤方法结束，方法外打印p中变量的值，由于p和pCopy中存的都是①中Product的地址，但是①中⑥Product里的值发生了改变， 所以，方法外打印p的值，是方法执行以后的。我们看到的效果是封装类型的值是改变的。String在传递过程中的步骤： ①虚拟机在堆中开辟一块内存，并存值”ab”。 ②虚拟机在栈中分配给str一个内存，内存中存的是①中的地址。 ③虚拟机复制一份str，我们叫strCopy，str和strCopy内存不同，但存的值都是①的地址。 ④将strCopy传入方法体 ⑤方法体在堆中开辟一块内存，并存值”cd”(因为String内存不可变故只可开辟一个新内存) ⑥方法体将strCopy的值改变，存入⑤的内存地址 ⑦方法结束，方法外打印str，由于str存的是①的地址，所有打印结果是”ab”String 底层 Hashtable 结构的说明：
字符串常量池是不会存储相同内容的字符串的
String的String Pool是一个固定大小的Hashtable，默认值大小长度是1009。如果放进String Pool的String非常多，就会造成Hash冲突严重，从而导致链表会很长，而链表长了后直接会造成的影响就是当调用String.intern()方法时性能会大幅下降。
使用-XX:StringTablesize可设置StringTable的长度
在JDK6中StringTable是固定的，就是1009的长度，所以如果常量池中的字符串过多就会导致效率下降很快，StringTablesize设置没有要求
在JDK7中，StringTable的长度默认值是60013，StringTablesize设置没有要求
在JDK8中，StringTable的长度默认值是60013，StringTable可以设置的最小值为1009
String 类型：
在Java语言中有8种基本数据类型和一种比较特殊的类型String。这些类型为了使它们在运行过程中速度更快、更节省内存，都提供了一种常量池的概念。常量池就类似一个Java系统级别提供的缓存。8种基本数据类型的常量池都是系统协调的，String类型的常量池比较特殊。它的主要使用方法有两种。直接使用双引号声明出来的String对象会直接存储在常量池中。比如：String info=“atguigu.com”;如果不是用双引号声明的String对象，可以使用String提供的intern()方法。String 内存分配的演进过程：
Java 6及以前，字符串常量池存放在永久代
Java 7中 Oracle的工程师对字符串池的逻辑做了很大的改变，即将字符串常量池的位置调整到Java堆内 ①所有的字符串都保存在堆（Heap）中，和其他普通对象一样，这样可以让你在进行调优应用时仅需要调整堆大小就可以了。 ②字符串常量池概念原本使用得比较多，但是这个改动使得我们有足够的理由让我们重新考虑在Java 7中使用String.intern()。
Java8元空间，字符串常量在堆
StringTable 为什么要调整？
永久代的默认比较小永久代垃圾回收频率低堆中空间足够大，字符串可被及时回收在JDK 7中，interned字符串不再在Java堆的永久代中分配，而是在Java堆的主要部分（称为年轻代和年老代）中分配，与应用程序创建的其他对象一起分配。此更改将导致驻留在主Java堆中的数据更多，驻留在永久生成中的数据更少，因此可能需要调整堆大小。核心思想：
Java语言规范里要求完全相同的字符串字面量，应该包含同样的Unicode字符序列（包含同一份码点序列的常量），并且必须是指向同一个String类实例。字符串拼接操作的结论：
常量与常量的拼接结果在常量池，原理是编译期优化常量池中不会存在相同内容的变量拼接前后，只要其中有一个是变量，结果就在堆中。变量拼接的原理是StringBuilder如果拼接的结果调用intern()方法，则主动将常量池中还没有的字符串对象放入池中，并返回此对象地址 ①如果存在，则返回字符串在常量池中的地址 ②如果字符串常量池中不存在该字符串，则在常量池中创建一份，并返回此对象的地址字符串拼接操作不一定使用的是StringBuilder：
如果拼接符号左右两边都是字符串常量或常量引用，则仍然使用编译期优化，即非StringBuilder的方式。针对于final修饰类、方法、基本数据类型、引用数据类型的量的结构时，能使用上final的时候建议使用上。体会执行效率：通过StringBuilder的append()的方式添加字符串的效率要远高于使用String的字符串拼接方式：
分析原因： ① StringBuilder的append()的方式： 自始至终中只创建过一个StringBuilder的对象 使用String的字符串拼接方式：创建过多个StringBuilder和String的对象 ② 使用String的字符串拼接方式： 内存中由于创建了较多的StringBuilder和String的对象，内存占用更大； 如果进行GC，需要花费额外的时间。改进的空间： ①在实际开发中，如果基本确定要前前后后添加的字符串长度不高于某个限定值highLevel的情况下,建议使用构造器实例化：StringBuilder s = new StringBuilder(highLevel);//new char[highLevel]关于 intern() 方法的说明：
intern是一个native方法，调用的是底层C的方法字符串池最初是空的，由String类私有地维护。在调用intern方法时，如果池中已经包含了由equals(object)方法确定的与该字符串对象相等的字符串，则返回池中的字符串。否则，该字符串对象将被添加到池中，并返回对该字符串对象的引用。如果不是用双引号声明的String对象，可以使用String提供的intern方法：intern方法会从字符串常量池中查询当前字符串是否存在，若不存在就会将当前字符串放入常量池中。比如： String myInfo = new string("I love atguigu").intern(); 也就是说，如果在任意字符串上调用String.intern方法，那么其返回结果所指向的那个类实例，必须和直接以常量形式出现的字符串实例完全相同。因此，下列表达式的值必定是true ("a"+"b"+"c").intern()=="abc" 通俗点讲，Interned String就是确保字符串在内存里只有一份拷贝，这样可以节约内存空间，加快字符串操作任务的执行速度。注意，这个值会被存放在字符串内部池（String Intern Pool）new String() 的说明：
new String(“ab”)会创建几个对象？看字节码，就知道是两个。 ①一个对象是：new关键字在堆空间创建的 ②另一个对象是：字符串常量池中的对象"ab"。 字节码指令：ldc
new String(“a”) + new String(“b”)会创建几个对象？ ①对象1：new StringBuilder() ②对象2： new String(“a”) ③对象3： 常量池中的"a" ④对象4： new String(“b”) ⑤对象5： 常量池中的"b" ⑥深入剖析： StringBuilder的toString(): ⑦对象6 ：new String(“ab”) 俺爸强调一下，toString()的调用，在字符串常量池中，没有生成"ab"
代码分析：
/** * 如何保证变量s指向的是字符串常量池中的数据呢？有两种方式： * 方式一： String s = "shkstart";//字面量定义的方式 * 方式二： 调用intern() * String s = new String("shkstart").intern(); * String s = new StringBuilder("shkstart").toString().intern(); * * @author shkstart shkstart@126.com * @create 2020 18:49 */ public class StringIntern { public static void main(String[] args) { String s = new String("1"); s.intern();//这方法其实没啥屌用，调用此方法之前，字符串常量池中已经存在"1" String s2 = "1"; /* jdk6：false jdk7/8：false 因为 s 指向堆空间中的 "1" ，s2 指向字符创常量池中的 "1" */ System.out.println(s == s2); // 执行完下一行代码以后，字符串常量池中，是否存在"11"呢？答案：不存在！！ String s3 = new String("1") + new String("1");//s3变量记录的地址为：new String("11") /* 如何理解：jdk6:创建了一个新的对象"11",也就有新的地址。 jdk7:此时常量中并没有创建"11",而是在常量池中记录了指向堆空间中new String("11")的地址（节省空间） */ s3.intern(); // 在字符串常量池中生成"11"。 String s4 = "11";//s4变量记录的地址：使用的是上一行代码代码执行时，在常量池中生成的"11"的地址 // jdk6：false jdk7/8：true System.out.println(s3 == s4); } }JDK6 ：正常眼光判断即可 ①new String() 即在堆中 ②str.intern() 则把字符串放入常量池中
JDK7/8 ：这就有点不一样了 ①new String() 即在堆中 ②str.intern() 则把字符串放入常量池中，出于节省空间的目的，如果 str 不存在于字符串常量池中，则将 str 在堆中的引用存储在字符串常量池中，没错，字符串常量池中存的是 str 在堆中的引用，所以 s3 == s4 为 true
关于 intern() 的总结：
JDK1.6中，将这个字符串对象尝试放入串池。 ①如果串池中有，则并不会放入。返回已有的串池中的对象的地址 ②如果没有，会把此对象复制一份，放入串池，并返回串池中的对象地址
JDK1.7起，将这个字符串对象尝试放入串池。 ①如果串池中有，则并不会放入。返回已有的串池中的对象的地址 ②如果没有，则会把对象的引用地址复制一份，放入串池，并返回串池中的引用地址
结论：
对于程序中大量使用存在的字符串时，尤其存在很多已经重复的字符串时，使用intern()方法能够节省内存空间。大的网站平台，需要内存中存储大量的字符串。比如社交网站，很多人都存储：北京市、海淀区等信息。这时候如果字符串都调用intern()方法，就会很明显降低内存的大小。String 去重操作的背景：
背景：对许多Java应用（有大的也有小的）做的测试得出以下结果： ①堆存活数据集合里面String对象占了25% ②堆存活数据集合里面重复的String对象有13.5% ③String对象的平均长度是45许多大规模的Java应用的瓶颈在于内存，测试表明，在这些类型的应用里面，Java堆中存活的数据集合差不多25%是String对象。更进一步，这里面差不多一半String对象是重复的，重复的意思是说：str1.equals(str2)= true。堆上存在重复的String对象必然是一种内存的浪费。这个项目将在G1垃圾收集器中实现自动持续对重复的String对象进行去重，这样就能避免浪费内存。String 去重的的具体实现：
当垃圾收集器工作的时候，会访问堆上存活的对象。对每一个访问的对象都会检查是否是候选的要去重的String对象。
如果是，把这个对象的一个引用插入到队列中等待后续的处理。一个去重的线程在后台运行，处理这个队列。处理队列的一个元素意味着从队列删除这个元素，然后尝试去重它引用的String对象。
使用一个Hashtable来记录所有的被String对象使用的不重复的char数组。当去重的时候，会查这个Hashtable，来看堆上是否已经存在一个一模一样的char数组。
如果存在，String对象会被调整引用那个数组，释放对原来的数组的引用，最终会被垃圾收集器回收掉。
如果查找失败，char数组会被插入到Hashtable，这样以后的时候就可以共享这个数组了。
命令行选项：
UseStringDeduplication(bool) ：开启String去重，默认是不开启的，需要手动开启。PrintStringDeduplicationStatistics(bool) ：打印详细的去重统计信stringDeduplicationAgeThreshold(uintx) ：达到这个年龄的String对象被认为是去重的候选对象