05-JVM调优实战

最新推荐文章于 2024-09-06 15:13:50 发布

温柔的皮卡丘

最新推荐文章于 2024-09-06 15:13:50 发布

阅读量189

点赞数

分类专栏： JVM 文章标签： jvm java 开发语言

本文链接：https://blog.csdn.net/weixin_44318459/article/details/127355865

版权

JVM 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

文章目录

- JVM调优常用命令

JVM调优常用命令

Jps

用于查看Java进程ID
在这里插入图片描述

Jmap

jmap（Memory Map for Java）命令用于生成堆转储快照（一般称为heapdump或dump文件），jmap的作用并不仅仅是为了获取堆转储快照，它还可以查询finalize执行队列、Java堆和方法区的详细信息，如空间使用率、当前用的是哪种收集器等。

jmap -histo pid 查看历史生成的实例
jmap -histo : live pid 查看当前存活的示例，执行过程中可能会触发一次full gc

查看当前实例信息

在这里插入图片描述
打开live.txt文件内容如下

num：序号
nstances：实例数量
bytes：占用空间大小
class name：类名称，[C is a char[]，[B is a byte[]，[I is a int[]

查看堆信息

命令：jmap -heap pid
在这里插入图片描述

导出堆堆转储快照

jmap -dump:format=b,file=eureka.hprof pid 手动当初当前堆堆转储快照
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath={filename} jvm设置此参数，当内存溢出时自动导出文件到指定目录
代码模拟示例：

/**
 * JVM设置
 * -Xms10M -Xmx10M -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\jvm.dump 
 */
public class DumpTest {

    public static List<Object> list = new ArrayList<>();
    
    public static void main(String[] args) {
        List<Object> list = new ArrayList<>();
        int i = 0;
        int j = 0;
        while (true) {
            list.add(new User(i++, UUID.randomUUID().toString()));
            new User(j--, UUID.randomUUID().toString());
        }
    }
    
}

运行结果：
在这里插入图片描述
使用jdk自带工具jvisualvm来分析dump文件

在这里插入图片描述
概要信息中可以大致告诉我们发生了什么，我们点击main会直接跳转到错误位置：

上图可以看到具体哪段代码出现的问题。
点击类也可以查看当前堆中对象实例个数

Jstack

jstack（Stack Trace for Java）命令用于生成虚拟机当前时刻的线程快照（一般称为threaddump或者
javacore文件）。
生成线程快照的目的通常是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间挂起等。

查看进程死锁

命令：jstack pid
代码示例：

public class JstackTest {

    private static Object lock1 = new Object();
    private static Object lock2 = new Object();

    public static void main(String[] args) {
        new Thread(() -> {
            synchronized (lock1) {
                try {
                    System.out.println("thread1 begin");
                    Thread.sleep(5000);
                } catch (InterruptedException e) {
                }
                synchronized (lock2) {
                    System.out.println("thread1 end");
                }
            }
        }).start();

        new Thread(() -> {
            synchronized (lock2) {
                try {
                    System.out.println("thread2 begin");
                    Thread.sleep(5000);
                } catch (InterruptedException e) {
                }
                synchronized (lock1) {
                    System.out.println("thread2 end");
                }
            }
        }).start();

        System.out.println("main thread end");
    }
    
}

查看死锁
在这里插入图片描述

“Thread-1” 线程名
prio=5 优先级=5
tid=0x0000000002df2800 线程id
nid=0xae18 线程对应的本地线程标识nid
java.lang.Thread.State: BLOCKED 线程状态
死锁信息

另外，还可以用jvisualvm自动检测死锁。
在这里插入图片描述

找出CPU占用最高的线程

package org.example;

public class Math {
    
    public static final int initData = 666;

    public int compute() { 
        int a = 1;
        int b = 2;
        int c = (a + b) * 10;
        return c;
    }

    public static void main(String[] args) {
        Math math = new Math();
        // 死循环执行，让cpu飙高
        while (true) {
            math.compute();
        }
    }
}

让我们在Linux环境上运行上述代码，可以在本地编译好class文件，在Linux环境上创建对应包路径的文件目录，上传class文件，然后执行运行代码。
在这里插入图片描述
查看进程

接下来我们正式排查CPU飙高的原因。
1、使用命令top -p <pid> 来查看java进程的内存情况。pid为进程ID，这里我们的java进程ID为3456
在这里插入图片描述
2、按H获取每个线程的内存情况

可以看到ID为3457的线程CPU使用率接近百分百。
3、将CPU占用最高的线程ID转换为16进制，得到d81（注意要使用小写字母）
4、执行命令 jstack 3456|grep -A 10 d81，得到线程堆栈信息中 d81 这个线程所在行的后面10行，从堆栈中可以发现导致cpu飙高的调用方法。
在这里插入图片描述
5、根据堆栈信息，找到对应的代码位置。

Jinfo

jinfo（Configuration Info for Java）的作用是实时查看正在运行的Java应用程序的扩展参数。

查看jvm运行参数

jinfo -flags <pid>
在这里插入图片描述

查看java系统参数

jinfo -sysprops <pid> 可以查得由System.getProperties()取得的参数
在这里插入图片描述

Jstat

jstat命令可以查看堆内存各部分的使用量，以及加载类的数量。命令的格式如下：
jstat [-命令选项] [vmid] [间隔时间(毫秒)] [查询次数]

垃圾回收统计

jstat -gc pid 最常用，可以评估程序内存使用及GC压力整体情况
在这里插入图片描述

S0C：第一个幸存区的大小，单位KB
S1C：第二个幸存区的大小
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小
EC：伊甸园区的大小
EU：伊甸园区的使用大小
OC：老年代大小
OU：老年代使用大小
MC：方法区大小(元空间)
MU：方法区使用大小
CCSC:压缩类空间大小
CCSU:压缩类空间使用大小
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间，单位s
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间，单位s
GCT：垃圾回收消耗总时间，单位s

堆内存统计

jstat -gccapacity <pid>
在这里插入图片描述

NGCMN：新生代最小容量
NGCMX：新生代最大容量
NGC：当前新生代容量
S0C：第一个幸存区大小
S1C：第二个幸存区的大小
EC：伊甸园区的大小
OGCMN：老年代最小容量
OGCMX：老年代最大容量
OGC：当前老年代大小
OC:当前老年代大小
MCMN:最小元数据容量
MCMX：最大元数据容量
MC：当前元数据空间大小
CCSMN：最小压缩类空间大小
CCSMX：最大压缩类空间大小
CCSC：当前压缩类空间大小
YGC：年轻代gc次数
FGC：老年代GC次数

新生代垃圾回收统计

jstat -gcnew <pid>
在这里插入图片描述

S0C：第一个幸存区的大小
S1C：第二个幸存区的大小
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小
TT:对象在新生代存活的次数
MTT:对象在新生代存活的最大次数
DSS:期望的幸存区大小
EC：伊甸园区的大小
EU：伊甸园区的使用大小
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间

新生代内存统计

jstat -gcnewcapacity <pid>
在这里插入图片描述

NGCMN：新生代最小容量
NGCMX：新生代最大容量
NGC：当前新生代容量
S0CMX：最大幸存1区大小
S0C：当前幸存1区大小
S1CMX：最大幸存2区大小
S1C：当前幸存2区大小
ECMX：最大伊甸园区大小
EC：当前伊甸园区大小
YGC：年轻代垃圾回收次数
FGC：老年代回收次数

老年代垃圾回收统计

jstat -gcold <pid>
在这里插入图片描述

OGCMN：老年代最小容量
OGCMX：老年代最大容量
OGC：当前老年代大小
OC：老年代大小
YGC：年轻代垃圾回收次数
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间

元数据空间统计

jstat -gcmetacapacity <pid>
在这里插入图片描述

MCMN:最小元数据容量
MCMX：最大元数据容量
MC：当前元数据空间大小
CCSMN：最小压缩类空间大小
CCSMX：最大压缩类空间大小
CCSC：当前压缩类空间大小
YGC：年轻代垃圾回收次数
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间

堆内存使用空间占比

jstat -gcutil <pid>
在这里插入图片描述

S0：幸存1区当前使用比例
S1：幸存2区当前使用比例
E：伊甸园区使用比例
O：老年代使用比例
M：元数据区使用比例
CCS：压缩使用比例
YGC：年轻代垃圾回收次数
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间

JVM运行情况预估

用 jstat gc -pid 命令可以计算出如下一些关键数据，有了这些数据就可以采用之前介绍过的优化思路，先给自己的系统设置一些初始性的JVM参数，比如堆内存大小，年轻代大小，Eden和Survivor的比例，老年代的大小，大对象的阈值，大龄对象进入老年代的阈值等。

年轻代对象增长的速率

可以执行命令 jstat -gc pid 1000 10 (每隔1秒执行1次命令，共执行10次)，通过观察EU(eden区的使用)来估算每秒eden大概新增多少对象，如果系统负载不高，可以把频率1秒换成1分钟，甚至10分钟来观察整体情况。注意，一般系统可能有高峰期和日常期，所以需要在不同的时间分别估算不同情况下对象增长速率。

Young GC的触发频率和每次耗时

知道年轻代对象增长速率我们就能推根据eden区的大小推算出Young GC大概多久触发一次，Young GC的平均耗时可以通过 YGCT/YGC 公式算出，根据结果我们大概就能知道系统大概多久会因为Young GC的执行而卡顿多久。

每次Young GC后有多少对象存活和进入老年代

这个因为之前已经大概知道Young GC的频率，假设是每5分钟一次，那么可以执行命令 jstat -gc pid 300000 10 ，观察每次结果eden，survivor和老年代使用的变化情况，在每次gc后eden区使用一般会大幅减少，survivor和老年代都有可能增长，这些增长的对象就是每次Young GC后存活的对象，同时还可以看出每次Young GC后进去老年代大概多少对象，从而可以推算出老年代对象增长速率。

Full GC的触发频率和每次耗时

知道了老年代对象的增长速率就可以推算出Full GC的触发频率了，Full GC的每次耗时可以用公式 FGCT/FGC 计算得出。

优化思路

其实简单来说就是尽量让每次Young GC后的存活对象小于Survivor区域的50%，都留存在年轻代里。尽量别让对象进入老年代。尽量减少Full GC的频率，避免频繁Full GC对JVM性能的影响。

阿里巴巴Arthas详解

Arthas 是 Alibaba 在 2018 年 9 月开源的 Java 诊断工具。支持 JDK6+，采用命令行交互模式，可以方便的定位和诊断线上程序运行问题。Arthas 官方文档十分详细，详见：https://alibaba.github.io/arthas

Arthas使用场景

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

是否有一个全局视角来查看系统的运行状况？
为什么 CPU 又升高了，到底是哪里占用了 CPU ？
运行的多线程有死锁吗？有阻塞吗？
程序运行耗时很长，是哪里耗时比较长呢？如何监测呢？
这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？
我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？
遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？
有什么办法可以监控到 JVM 的实时运行状态？

Arthas使用

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

现在服务器上运行一个程序，代码如下：

package org.example;

import java.util.HashSet;

public class ArthasDemo {

    private static HashSet hashSet = new HashSet();

    public static void main(String[] args) {
        cpuHigh();
        addHashSetThread();
        deadThread();
    }

    /**
     * 模拟CPU过高
     */
    public static void cpuHigh() {
        new Thread(() -> {
            while (true) {

            }
        }).start();
    }

    /**
     * 不断的向 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();
    }


    /**
     * 死锁
     */
    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();
    }
    
}

用java -jar运行即可，可以识别机器上所有Java进程
在这里插入图片描述
选择进程序号1，进入进程信息操作

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

输入thread可以查看线程详细情况
在这里插入图片描述
输入 thread加上线程ID 可以查看线程堆栈

输入 thread -b 可以查看线程死锁

输入 jad加类的全名可以反编译，这样可以方便我们查看线上代码是否是正确的版本

使用 ognl 命令可以修改线上代码

更多命令参考：https://arthas.aliyun.com/doc/commands.html

Class常量池与运行时常量池

Class常量池可以理解为是Class文件中的资源仓库。 Class文件中除了包含类的版本、字段、方法、接口等描述信息外，还有一项信息就是常量池(constant pool table)，用于存放编译期生成的各种字面量(Literal)和符号引用(Symbolic References)。

我们一般可以通过javap命令生成更可读的JVM字节码指令文件：
javap -v Math.class
在这里插入图片描述
红框标出的就是class常量池信息，常量池中主要存放两大类常量：字面量和符号引用。

字面量

字面量就是指由字母、数字等构成的字符串或者数值常量。
字面量只可以右值出现，所谓右值是指等号右边的值，如：int a=1 这里的a为左值，1为右值。在这个例子中1就是字面量。

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

符号引用

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

类和接口的全限定名
字段的名称和描述符
方法的名称和描述符

上面的a，b就是字段名称，就是一种符号引用，还有Math类常量池里的 Lcom/tuling/jvm/Math 是类的全限定名，main和compute是方法名称，()是一种UTF8格式的描述符，这些都是符号引用。

这些常量池现在是静态信息，只有到运行时被加载到内存后，这些符号才有对应的内存地址信息，这些常量池一旦被装入内存就变成运行时常量池，对应的符号引用在程序加载或运行时会被转变为被加载到内存区域的代码的直接引用，也就是我们说的动态链接了。

例如，compute()这个符号引用在运行时就会被转变为compute()方法具体代码在内存中的地址，主要通过对象头里的类型指针去转换直接引用。

字符串常量池

字符串常量池的设计思想

1、字符串的分配，和其他的对象分配一样，耗费高昂的时间与空间代价，作为最基础的数据类型，大量频繁的创建字符串，极大程度地影响程序的性能
2、JVM为了提高性能和减少内存开销，在实例化字符串常量的时候进行了一些优化

为字符串开辟一个字符串常量池，类似于缓存区
创建字符串常量时，首先查询字符串常量池是否存在该字符串
存在该字符串，返回引用实例，不存在，实例化该字符串并放入池中

三种字符串操作(Jdk1.7 及以上版本)

直接赋值字符串

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

这种方式创建的字符串对象，只会在常量池中。因为有"aba"这个字面量，创建对象s的时候，JVM会先去常量池中通过 equals(key) 方法，判断是否有相同的对象，如果有，则直接返回该对象在常量池中的引用，如果没有，则会在常量池中创建一个新对象，再返回引用。

new String();

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

这种方式会保证字符串常量池和堆中都有这个对象，没有就创建，最后返回堆内存中的对象引用。
步骤大致如下：

因为有"aba"这个字面量，所以会先检查字符串常量池中是否存在字符串"aba"。
不存在，先在字符串常量池里创建一个字符串对象；再去内存中创建一个字符串对象"aba"；
存在的话，就直接去堆内存中创建一个字符串对象"zhuge"；
最后，将内存中的引用返回。

intern方法

String s1 = new String("aba");   
String s2 = s1.intern();
System.out.println(s1 == s2);  //false

String中的intern方法是一个 native 的方法，当调用 intern方法时，如果池已经包含一个等于此String对象的字符串（用equals(oject)方法确定），则返回池中的字符串。否则，将intern返回的引用指向当前字符串 s1(jdk1.6版本需要将 s1 复制到字符串常量池里)。

字符串常量池位置

Jdk1.6及之前：有永久代, 运行时常量池在永久代，运行时常量池包含字符串常量池
Jdk1.7：有永久代，但已经逐步“去永久代”，字符串常量池从永久代里的运行时常量池分离到堆里
Jdk1.8及之后：无永久代，运行时常量池在元空间，字符串常量池里依然在堆里
用一个程序证明下字符串常量池在哪里：

/**
 * jdk6：-Xms6M -Xmx6M -XX:PermSize=6M -XX:MaxPermSize=6M  
 * jdk8：-Xms6M -Xmx6M -XX:MetaspaceSize=6M -XX:MaxMetaspaceSize=6M
 */
public class RuntimeConstantPoolOOM{
    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

字符串常量池设计原理

字符串常量池底层是hotspot的C++实现的，底层类似一个 HashTable，保存的本质上是字符串对象的引用。
来看一道常见的面试题，下面代码创建了多少个对象？

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，但这些对象确实存在或存在过

为什么输出会有这些变化呢？主要还是字符串池从永久代中脱离、移入堆区的原因， intern() 方法也相应发生了变化：

在 JDK 1.6 中，调用 intern() 首先会在字符串池中寻找 equal() 相等的字符串，假如字符串存在就返回该字符串在字符串池中的引用；假如字符串不存在，虚拟机会重新在永久代上创建一个实例，将 StringTable 的一个表项指向这个新创建的实例。
在 JDK 1.7 (及以上版本)中，由于字符串池不在永久代了，intern() 做了一些修改，更方便地利用堆中的对象。字符串存在时和 JDK 1.6一样，但是字符串不存在时不再需要重新创建实例，可以直接指向堆上的实例。

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

String常量池问题的几个例子
示例1：

String s0="hello";
String s1="hello";
String s2="he" + "llo";
System.out.println( s0==s1 ); //true
System.out.println( s0==s2 ); //true

分析：因为例子中的 s0和s1中的”hello”都是字符串常量，它们在编译期就被确定了，所以s0==s1为true；而”he”和”llo”也都是字符串常量，当一个字符串由多个字符串常量连接而成时，它自己肯定也是字符串常量，所以s2也同样在编译期就被优化为一个字符串常量"hello"，所以s2也是常量池中” hello”的一个引用。所以我们得出s0==s1==s2；

示例2：

String s0="hello";
String s1=new String("hello");
String s2="he" + new String("llo");
System.out.println( s0==s1 );　　// false
System.out.println( s0==s2 )；　 // false
System.out.println( s1==s2 );　　// false

分析：用new String() 创建的字符串不是常量，不能在编译期就确定，所以new String() 创建的字符串不放入常量池中，它们有自己的地址空间。
s0还是常量池中"hello”的引用，s1因为无法在编译期确定，所以是运行时创建的新对象”hello”的引用，s2因为有后半部分 new String(”llo”)所以也无法在编译期确定，所以也是一个新创建对象”hello”的引用;明白了这些也就知道为何得出此结果了。

示例3：

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

分析：JVM对于字符串常量的"+“号连接，将在程序编译期，JVM就将常量字符串的”+“连接优化为连接后的值，拿"a” + 1来说，经编译器优化后在class中就已经是a1。在编译期其字符串常量的值就确定下来，故上面程序最终的结果都为true。

示例4：

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

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

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

示例5：

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

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

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

示例6：

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

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

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

分析：JVM对于字符串引用bb，它的值在编译期无法确定，只有在程序运行期调用方法后，将方法的返回值和"a"来动态连接并分配地址为b，故上面程序的结果为false。

关于String是不可变的
通过上面例子可以得出得知：

String  s  =  "a" + "b" + "c";  //就等价于String s = "abc";
String  a  =  "a";
String  b  =  "b";
String  c  =  "c";
String  s1  =   a  +  b  +  c;

s1 这个就不一样了，可以通过观察其JVM指令码发现s1的"+"操作会变成如下操作：

StringBuilder temp = new StringBuilder();
temp.append(a).append(b).append(c);
String s = temp.toString();

最后再看一个例子：

//字符串常量池："计算机"和"技术"     堆内存：str1引用的对象"计算机技术"  
//堆内存中还有个StringBuilder的对象，但是会被gc回收，StringBuilder的toString方法会new String()，这个String才是真正返回的对象引用
String str2 = new StringBuilder("计算机").append("技术").toString();   //没有出现"计算机技术"字面量，所以不会在常量池里生成"计算机技术"对象
System.out.println(str2 == str2.intern());  //true
//"计算机技术" 在池中没有，但是在heap中存在，则intern时，会直接返回该heap中的引用

//字符串常量池："ja"和"va"     堆内存：str1引用的对象"java"  
//堆内存中还有个StringBuilder的对象，但是会被gc回收，StringBuilder的toString方法会new String()，这个String才是真正返回的对象引用
String str1 = new StringBuilder("ja").append("va").toString();    //没有出现"java"字面量，所以不会在常量池里生成"java"对象
System.out.println(str1 == str1.intern());  //false
//java是关键字，在JVM初始化的相关类里肯定早就放进字符串常量池了

String s1=new String("test");  
System.out.println(s1==s1.intern());   //false
//"test"作为字面量，放入了池中，而new时s1指向的是heap中新生成的string对象，s1.intern()指向的是"test"字面量之前在池中生成的字符串对象

String s2=new StringBuilder("abc").toString();
System.out.println(s2==s2.intern());  //false
//同上

温柔的皮卡丘

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
05-JVM调优实战

这个因为之前已经大概知道Young GC的频率，假设是每5分钟一次，那么可以执行命令 jstat -gc pid 300000 10 ，观察每次结果eden，survivor和老年代使用的变化情况，在每次gc后eden区使用一般会大幅减少，survivor和老年代都有可能增长，这些增长的对象就是每次Young GC后存活的对象，同时还可以看出每次Young GC后进去老年代大概多少对象，从而可以推算出老年代对象增长速率。在编译期其字符串常量的值就确定下来，故上面程序最终的结果都为true。
复制链接

扫一扫