jvm.txt

阿里小哥带你玩转JVM：揭秘try-catch-finally在JVM底层都干了些啥？

BAT 面试官是如何360°无死角考察候选人的（上篇）

每秒上万并发下的Spring Cloud参数优化实战

分布式事务如何保障实际生产中99.99%高可用

记一位朋友斩获 BAT 技术专家Offer的面试经历

亿级流量架构系列之如何支撑百亿级数据的存储与计算


让我们准备一个函数:







然后，反编译他的字节码：





首先我们介绍异常表：在编译生成的字节码中，每个方法都附带一个异常表。



异常表中的每一个条目代表一个异常处理器，并且由 from 指针、to 指针、target 指针以及所捕获的异常类型构成。这些指针的值是字节码索引用以定位字节码。


下图就是我特别指出的JVM字节码中的异常表部分。



我们来分析一下这几个语句的执行流程，首先执行：



这相当于执行：




再来：





上图相当于执行





有人问：try去哪了？



我马上就要介绍。此时idiv执行完就有异常了，有异常了先找异常表。




我再贴一下异常表，他是怎么搜索的呢？



当程序触发异常时，Java 虚拟机会从上至下遍历异常表中的所有条目。



当触发异常的字节码的索引值在某个异常表条目的监控范围内，Java 虚拟机会判断所抛出的异常和该条目想要捕获的异常是否匹配。



如果匹配，Java 虚拟机会将控制流转移至该条目 target 指针指向的字节码。


我们看 ，是第四个索引指向的字节码出了问题，显然，此时应该匹配红线这一条记录，从而跳转到第14个索引的字节码。


我们看他怎么做的？




new出一个RuntimeException并抛出，它就是







这一句，按照我们刚才的流程，此时依然需要找到这个RuntimeException在哪个异常表的条目中





此时匹配到异常表的条目，跳转到字节码索引23



继续抛出RuntimeExcpetion，可以注意到 这实际上对应了



这个语句，于是我们可以知道，在三个都出现异常的情况下，实际上最终向外抛出的异常是finally里面的异常。



可以看到当31索引处调用athrow语句抛出异常时，此时异常表没有任何一个条目能够匹配该异常，此时怎么办呢？





如果遍历完所有异常表条目，Java 虚拟机仍未匹配到异常处理器，那么它会弹出当前方法对应的 Java 栈帧，并且在调用者中重复上述操作。



在最坏情况下，Java 虚拟机需要遍历当前线程 Java 栈上所有方法的异常表。


事实上分析以上的整体的全部语句你可以发现，jvm层面有真正的finally吗？



没有



现在的做法是，复制 finally 代码块的内容，分别放在 try-catch 代码块所有正常执行路径以及异常执行路径的出口中。无论是否出现异常，确保一定会执行finally语句。



刚才catch出了异常，依然执行finally语句就可以发现这一点。至于其他路径，大家可以自行验证。我就在这里抛砖引玉了。


至于为什么2-6发生任何异常都跳转到23？大家可以自己想一下这个问题。


我就提示一点 2-6 target为14的条目代表的catch是不能捕获所有异常的，但是你要确保finally的语句能够执行。而2-6恰巧是try语句块的内容。23这个索引恰巧是finally语句的一份复制。


=======================


阿里面试题：字符串对象在JVM中是如何存放的


字符串对象在JVM中可能有两个存放的位置：字符串常量池或堆内存。

使用常量字符串初始化的字符串对象，它的值存放在字符串常量池中；

使用字符串构造方法创建的字符串对象，它的值存放在堆内存中；

String提供了一个API——java.lang.String.intern()，这个API可以手动将一个字符串对象的值转移到字符串常量池中。

在1.7之前，字符串常量池是在PermGen区域，这个区域的大小是固定的——不能在运行时根据需要扩大，也不能被垃圾收集器回收，因此如果程序中有太多的字符串调用了intern方法的话，就可能造成OOM。

在1.7以后，字符串常量池移到了堆内存中，并且可以被垃圾收集器回收，这个改动降低了字符串常量池OOM的风险。



知识点总结



2案例分析





验证代码：



public class StringTest {

    public static void main(String[] args) {
        String s1 = "javaadu";
        String s2 = "javaadu";
        String s3 = new String("javaadu");
        System.out.println(s1 == s2); //true
        System.out.println(s1 == s3); //false

        String s4 = s3.intern();
        System.out.println(s1 == s4); //true
    }
}




2intern源码分析
intern方法的实现底层是一个native方法，在Hotspot JVM里字符串常量池它的逻辑在注释里写得很清楚：如果常量池中有这个字符串常量，就直接返回，否则将该字符串对象的值存入常量池，再返回。



这里以Openjdk1.8的源码为例，跟下intern方法的底层实现，String.java文件对应的C文件是String.c：

JNIEXPORT jobject JNICALL
Java_java_lang_String_intern(JNIEnv *env, jobject this)
{
   return JVM_InternString(env, this);
}
JVM_InternString这个方法的定义在jvm.h，实现在jvm.cpp中，在JVM中，Java世界和C++世界的连接层就是jvm.h和jvm.cpp这两文件。

JVM_ENTRY(jstring, JVM_InternString(JNIEnv *env, jstring str))
 JVMWrapper("JVM_InternString");
 JvmtiVMObjectAllocEventCollector oam;
 if (str == NULL) return NULL;
 oop string = JNIHandles::resolve_non_null(str);
 oop result = StringTable::intern(string, CHECK_NULL);
 return (jstring) JNIHandles::make_local(env, result);
JVM_END
可以看出，字符串常量池在JVM内部就是一个HashTable，也就是上面代码中的StringTable。

从StringTable::intern方法跟下去，就可以发现：如果找到了这次操作的字符串，就直接返回found_string；如果没有找到，就将当前的字符串加入到HashTable中，然后再返回。



总结



在Java应用恰当得使用String.intern()方法有助于节省内存空间，但是在使用的时候，也需要注意，因为StringTable的大小是固定的，如果常量池中的字符串过多，会影响程序运行效率。



END

如果读完觉得有收获的话，欢迎点【好看】，关注【匠心零度】，查阅更多精彩历史！！！


=====================

（1）-Xms20M

表示设置JVM启动内存的最小值为20M，必须以M为单位

（2）-Xmx20M

表示设置JVM启动内存的最大值为20M，必须以M为单位。将-Xmx和-Xms设置为一样可以避免JVM内存自动扩展。大的项目-Xmx和-Xms一般都要设置到10G、20G甚至还要高

（3）-verbose:gc

表示输出虚拟机中GC的详细情况

（4）-Xss128k

表示可以设置虚拟机栈的大小为128k

（5）-Xoss128k

表示设置本地方法栈的大小为128k。不过HotSpot并不区分虚拟机栈和本地方法栈，因此对于HotSpot来说这个参数是无效的

（6）-XX:PermSize=10M

表示JVM初始分配的永久代的容量，必须以M为单位

（7）-XX:MaxPermSize=10M

表示JVM允许分配的永久代的最大容量，必须以M为单位，大部分情况下这个参数默认为64M

（8）-Xnoclassgc

表示关闭JVM对类的垃圾回收

（9）-XX:+TraceClassLoading

表示查看类的加载信息

（10）-XX:+TraceClassUnLoading

表示查看类的卸载信息

（11）-XX:NewRatio=4

表示设置年轻代：老年代的大小比值为1：4，这意味着年轻代占整个堆的1/5

（12）-XX:SurvivorRatio=8

表示设置2个Survivor区：1个Eden区的大小比值为2:8，这意味着Survivor区占整个年轻代的1/5，这个参数默认为8

（13）-Xmn20M

表示设置年轻代的大小为20M

（14）-XX:+HeapDumpOnOutOfMemoryError

表示可以让虚拟机在出现内存溢出异常时Dump出当前的堆内存转储快照

（15）-XX:+UseG1GC

表示让JVM使用G1垃圾收集器

（16）-XX:+PrintGCDetails

表示在控制台上打印出GC具体细节

（17）-XX:+PrintGC

表示在控制台上打印出GC信息

（18）-XX:PretenureSizeThreshold=3145728

表示对象大于3145728（3M）时直接进入老年代分配，这里只能以字节作为单位

（19）-XX:MaxTenuringThreshold=1

表示对象年龄大于1，自动进入老年代

（20）-XX:CompileThreshold=1000

表示一个方法被调用1000次之后，会被认为是热点代码，并触发即时编译

（21）-XX:+PrintHeapAtGC

表示可以看到每次GC前后堆内存布局

（22）-XX:+PrintTLAB

表示可以看到TLAB的使用情况

（23）-XX:+UseSpining

开启自旋锁

（24）-XX:PreBlockSpin

更改自旋锁的自旋次数，使用这个参数必须先开启自旋锁

怎么用MyEclipse设置虚拟机参数

右键类-->Run as-->Run Configurations...



Java Application里面选到自己的类，选择Arguments，VM arguments空白部分就可以设置虚拟机参数了。如果点击了Run Configurations没有出现自己的类的话也没关系，双击一下Java Application就好了



后记

Java虚拟机参数有上百个，性能调优中很大一块就是选择这上百个参数中的某些重要参数进行设置，并且根据项目运行情况对参数进行不断调整以求达到一个性能最佳点。性能调优说有捷径也有捷径，百度搜一份别人推荐的JVM参数设置改改就好了，那至于具体好不好就说不上了，但起码保证能用吧；性能调优说没捷径也没捷径，如果对JVM的性能有严苛的要求并且希望细化到每一个小点，达到能达到的最佳值，那首先就必须对于Java虚拟机，对于每一个虚拟机参数有着深刻的理解才行。最近几年兴起了一个叫做性能调优师的职位，也证明了性能优化的重要性，反正从个人的角度看，性能调优绝对是一门学问，不是那么简单的，打好基础才是王道。

1. Java 堆空间
发生频率：5颗星
造成原因
无法在 Java 堆中分配对象

吞吐量增加

应用程序无意中保存了对象引用，对象无法被 GC 回收

应用程序过度使用 finalizer。finalizer 对象不能被 GC 立刻回收。finalizer 由结束队列服务的守护线程调用，有时 finalizer 线程的处理能力无法跟上结束队列的增长

解决方案
使用 -Xmx 增加堆大小

修复应用程序中的内存泄漏

2. GC 开销超过限制
发生频率：5颗星
造成原因
Java 进程98%的时间在进行垃圾回收，恢复了不到2%的堆空间，最后连续5个（编译时常量）垃圾回收一直如此。

解决方案
使用 -Xmx 增加堆大小

使用 -XX:-UseGCOverheadLimit 取消 GC 开销限制

修复应用程序中的内存泄漏

3. 请求的数组大小超过虚拟机限制
发生频率：2颗星
造成原因
应用程序试图分配一个超过堆大小的数组

解决方案
使用 -Xmx 增加堆大小

修复应用程序中分配巨大数组的 bug

4. Perm gen 空间
发生频率：3颗星
造成原因
Perm gen 空间包含：

类的名字、字段、方法

与类相关的对象数组和类型数组

JIT 编译器优化

当 Perm gen 空间用尽时，将抛出异常。

解决方案
使用 -XX: MaxPermSize 增加 Permgen 大小

不重启应用部署应用程序可能会导致此问题。重启 JVM 解决

5. Metaspace
发生频率：3颗星
造成原因
从 Java 8 开始 Perm gen 改成了 Metaspace，在本机内存中分配 class 元数据（称为 metaspace）。如果 metaspace 耗尽，则抛出异常

解决方案
通过命令行设置 -XX: MaxMetaSpaceSize 增加 metaspace 大小

取消 -XX: maxmetsspacedize

减小 Java 堆大小,为 MetaSpace 提供更多的可用空间

为服务器分配更多的内存

可能是应用程序 bug，修复 bug

6. 无法新建本机线程
发生频率：5颗星
造成原因
内存不足，无法创建新线程。由于线程在本机内存中创建，报告这个错误表明本机内存空间不足

解决方案
为机器分配更多的内存

减少 Java 堆空间

修复应用程序中的线程泄漏。

增加操作系统级别的限制

- ulimit -a

用户进程数增大 (-u) 1800

使用 -Xss 减小线程堆栈大小

7. 杀死进程或子进程
发生频率：1颗星
造成原因
内核任务：内存不足结束器，在可用内存极低的情况下会杀死进程

解决方案
将进程迁移到不同的机器上

给机器增加更多内存

与其他 OOM 错误不同，这是由操作系统而非 JVM 触发的。

8. 发生 stack_trace_with_native_method
发生频率：1颗星
造成原因
本机方法（native method）分配失败

打印的堆栈跟踪信息，最顶层的帧是本机方法

解决方案
使用操作系统本地工具进行诊断

------------------


第1章　初探Java虚拟机 1
1.1 知根知底：追溯Java的发展历程 2
1.1.1 那些依托Java虚拟机的语言大咖们 2
1.1.2 Java发展史上的里程碑 2
1.2 跨平台的真相：Java虚拟机来做中介 4
1.2.1 理解Java虚拟机的原理 4
1.2.2 看清Java虚拟机的种类 5
1.3 一切看我的：Java语言规范 6
1.3.1 词法的定义 6
1.3.2 语法的定义 7
1.3.3 数据类型的定义 8
1.3.4 Java语言规范总结 9
1.4 一切听我的：Java虚拟机规范 9
1.5 数字编码就是计算机世界的水和电 10
1.5.1 整数在Java虚拟机中的表示 10
1.5.2 浮点数在Java虚拟机中的表示 12
1.6 抛砖引玉：编译和调试虚拟机 14
1.7 小结 19
第2章　认识Java虚拟机的基本结构 20
2.1 谋全局者才能成大器：看穿Java虚拟机的架构 20
2.2 小参数能解决大问题：学会设置Java虚拟机的参数 22
2.3 对象去哪儿：辨清Java堆 23
2.4 函数如何调用：出入Java栈 25
2.4.1 局部变量表 27
2.4.2 操作数栈 32
2.4.3 帧数据区 32
2.4.4 栈上分配 33
2.5 类去哪儿了：识别方法区 35
2.6 小结 37
第3章　常用Java虚拟机参数 38
3.1 一切运行都有迹可循：掌握跟踪调试参数 38
3.1.1 跟踪垃圾回收——读懂虚拟机日志 39
3.1.2 类加载/卸载的跟踪 42
3.1.3 系统参数查看 44
3.2 让性能飞起来：学习堆的配置参数 45
3.2.1 最大堆和初始堆的设置 45
3.2.2 新生代的配置 49
3.2.3 堆溢出处理 52
3.3 别让性能有缺口：了解非堆内存的参数配置 54
3.3.1 方法区配置 55
3.3.2 栈配置 55
3.3.3 直接内存配置 55
3.4 Client和Server二选一：虚拟机的工作模式 58
3.5 小结 59
第4章　垃圾回收概念与算法 60
4.1 内存管理清洁工：认识垃圾回收 60
4.2 清洁工具大PK：讨论常用的垃圾回收算法 61
4.2.1 引用计数法（Reference Counting） 62
4.2.2 标记清除法（Mark-Sweep） 63
4.2.3 复制算法（Copying） 64
4.2.4 标记压缩法（Mark-Compact） 66
4.2.5 分代算法（Generational Collecting） 67
4.2.6 分区算法（Region） 68
4.3 谁才是真正的垃圾：判断可触及性 69
4.3.1 对象的复活 69
4.3.2 引用和可触及性的强度 71
4.3.3 软引用——可被回收的引用 72
4.3.4 弱引用——发现即回收 76
4.3.5 虚引用——对象回收跟踪 77
4.4 垃圾回收时的停顿现象：Stop-The-World案例实战 79


1.1 从机器语言到Java——詹爷，你好 1

1.2 兼容的选择：一场生产力的革命 6

1.3 中间语言翻译 10

1.3.1 从中间语言翻译到机器码 11

1.3.2 通过C 程序翻译 11

1.3.3 直接翻译为机器码 13

1.3.4 本地编译 16

1.4 神奇的指令 18

1.4.1 常见汇编指令 20

1.4.2 JVM 指令 21


第2 章 Java 执行引擎工作原理：方法调用 25

2.1 方法调用 26

2.1.1 真实的机器调用 26

2.1.2 C 语言函数调用 41

2.2 JVM 的函数调用机制 47

2.3 函数指针 53

2.4 CallStub 函数指针定义 60

2.5 _call_stub_entry 例程 72

2.6 本章总结 114

第3 章 Java 数据结构与面向对象 115

3.1 从Java 算法到数据结构 116

3.2 数据类型简史 120

3.3 Java 数据结构之偶然性 127

3.4 Java 类型识别 130

3.4.1 class 字节码概述 131

3.4.2 魔数与JVM 内部的int 类型 134

3.4.3 常量池与JVM 内部对象模型 135

3.5 大端与小端 141

3.5.1 大端和小端的概念 144

3.5.2 大小端产生的本质原因 146

3.5.3 大小端验证 147

3.5.4 大端和小端产生的场景 149

3.5.5 如何解决字节序反转 152

3.5.6 大小端问题的避免 154

3.5.7 JVM 对字节码文件的大小端处理 154

3.6 本章总结 157

第4 章 Java 字节码实战 158

4.1 字节码格式初探 158

4.1.1 准备测试用例 159

4.1.2 使用javap 命令分析字节码文件 159

4.1.3 查看字节码二进制 162

4.2 魔数与版本 163

4.2.1 魔数 165

4.2.2 版本号 165

4.3 常量池 166

4.3.1 常量池的基本结构 166

4.3.2 JVM 所定义的11 种常量 167

4.3.3 常量池元素的复合结构 167

4.3.4 常量池的结束位置 169

4.3.5 常量池元素总数量 169

4.3.6 第一个常量池元素 170

4.3.7 第二个常量池元素 171

4.3.8 父类常量 171

4.3.9 变量型常量池元素 172

4.4 访问标识与继承信息 174

4.4.1 access_flags 174

4.4.2 this_class 175

4.4.3 super_class 176

4.4.4 interface 177

4.5 字段信息 177

4.5.1 fields_count 177

4.5.2 field_info fields[fields_count] 178

4.6 方法信息 182

4.6.1 methods_count 182

4.6.2 method_info methods[methods_count] 183

4.7 本章回顾 203

第5 章 常量池解析 204

5.1 常量池内存分配 206

5.1.1 常量池内存分配总体链路 207

5.1.2 内存分配 212

5.1.3 初始化内存 221

5.2 oop-klass 模型 222

5.2.1 两模型三维度 223

5.2.2 体系总览 224

5.2.3 oop 体系 226

5.2.4 klass 体系 229

5.2.5 handle 体系 232

5.2.6 oop、klass、handle 的相互转换 237

5.3 常量池klass 模型（1） 242

5.3.1 klassKlass 实例构建总链路 244

5.3.2 为klassOop 申请内存 248

5.3.3 klassOop 内存清零 251

5.3.4 初始化mark 251

5.3.5 初始化klassOop._metadata 256

5.3.6 初始化klass 257

5.3.7 自指 258

5.4 常量池klass 模型（2） 258

5.4.1 constantPoolKlass 模型构建 258

5.4.2 constantPoolOop 与klass 261

5.4.3 klassKlass 终结符 264

5.5 常量池解析 264

5.5.1 constantPoolOop 域初始化 264

5.5.2 初始化tag 266

5.5.3 解析常量池元素 267

第6 章 类变量解析 277

6.1 类变量解析 278

6.2 偏移量 282

6.2.1 静态变量偏移量 282

6.2.2 非静态变量偏移量 284

6.2.3 Java 字段内存分配总结 309

6.3 从源码看字段继承 315

6.3.1 字段重排与补白 316

6.3.2 private 字段可被继承吗 322

6.3.3 使用HSDB 验证字段分配与继承 325

6.3.4 引用类型变量内存分配 333

6.4 本章总结 338

第7 章 Java 栈帧 340

7.1 entry_point 例程生成 341

7.2 局部变量表创建 349

7.2.1 constMethod 的内存布局 349

7.2.2 局部变量表空间计算 352

7.2.3 初始化局部变量区 355

7.3 堆栈与栈帧 364

7.3.1 栈帧是什么 364

7.3.2 硬件对堆栈的支持 383

7.3.3 栈帧开辟与回收 386

7.3.4 堆栈大小与多线程 388

7.4 JVM 的栈帧 392

7.4.1 JVM 栈帧与大小确定 392

7.4.2 栈帧创建 396

7.4.3 局部变量表 418

7.5 栈帧深度与slot 复用 430

7.6 最大操作数栈与操作栈复用 433

7.7 本章总结 436

第8 章 类方法解析 437

8.1 方法签名解析与校验 442

8.2 方法属性解析 444

8.2.1 code 属性解析 444

8.2.2 LVT&LVTT 446

8.3 创建methodOop 452

8.4 Java 方法属性复制 456

8.5 与 458

8.6 查看运行时字节码指令 479

8.7 vtable 486

8.7.1 多态 486

8.7.2 C++中的多态与vtable 488

8.7.3 Java 中的多态实现机制 490

8.7.4 vtable 与invokevirtual 指令 497

8.7.5 HSDB 查看运行时vtable 499

8.7.6 miranda 方法 502

8.7.7 vtable 特点总结 505

8.7.8 vtable 机制逻辑验证 506

8.8 本章总结 508

第9 章 执行引擎 510

9.1 执行引擎概述 511

9.2 取指 513

9.2.1 指令长度 516

9.2.2 JVM 的两级取指机制 524

9.2.3 取指指令放在哪 529

9.2.4 程序计数器在哪里 531

9.3 译码 532

9.3.1 模板表 532

9.3.2 汇编器 538

9.3.3 汇编 546

9.4 栈顶缓存 555

9.5 栈式指令集 563

9.6 操作数栈在哪里 574

9.7 栈帧重叠 578

9.8 entry_point 例程机器指令 583

9.9 执行引擎实战 585

9.9.1 一个简单的例子 585

9.9.2 字节码运行过程分析 587

9.10 字节码指令实现 594

9.10.1 iconst_3 594

9.10.2 istore_0 596

9.10.3 iadd 597

9.11 本章总结 598

第10 章 类的生命周期 599

10.1 类的生命周期概述 599

10.2 类加载 602

10.2.1 类加载——镜像类与静态字段 609

10.2.2 Java 主类加载机制 614

10.2.3 类加载器的加载机制 620

10.2.4 反射加载机制 621

10.2.5 import 与new 指令 622

10.3 类的初始化 623

10.4 类加载器 626

10.4.1 类加载器的定义. 626

10.4.2 系统类加载器与扩展类加载器创建 632

10.4.3 双亲委派机制与破坏 634

10.4.4 预加载 636

10.4.5 引导类加载 638

10.4.6 加载、链接与延迟加载 639

10.4.7 父加载器 643

10.4.8 加载器与类型转换 646

10.5 类实例分配 647

10.5.1 栈上分配与逃逸分析 650

10.5.2 TLAB 654

10.5.3 指针碰撞与eden 区分配 655

10.5.4 清零 656

10.5.5 偏向锁 657

10.5.6 压栈与取指 658

10.6 本章总结 660

Introduction to JVM Languages
Credits
About the Author
About the Reviewer
www.PacktPub.com
Why subscribe?
Customer Feedback
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Reader feedback
Customer support
Downloading the example code
Downloading the color images of this book
Errata
Piracy
Questions
Java Virtual Machine
JVM implementations
Why develop on JVM?
JVM adapts to market changes
Java Class Library
Ecosystem
Scenario 1 – Using a JVM application server
Scenario 2 – Using a general high-level web application framework
Scenario 3 – Using a microservice framework
Popular use cases
Web applications
Big data
IoT
JVM concepts
Virtual machine
The JIT compiler
Primitive datatypes
Classes
Reference types
References and null references
Garbage collector
Example
Backward compatibility
Build tools
Java editions
Java SE
Java EE
Example – Java Persistence API as implemented by two application servers
Java ME
Other languages on JVM
Why choose a language other than Java?
Java is a very verbose language
Java is not ideal for everything or everyone
Missing classes in Java Class Library
Mixing JVM languages in a project
Increasing build process complexity
Language runtime libraries
Writing unit tests in a different language
Summary
Developing on the Java Virtual Machine
JDK
Installing JDK
Downloading JDK
Installing JDK on Windows
Installing JDK on macOS
Installing JDK on Linux
Downloading API documentation
Exploring JDK
The directory structure
JDK commands
GUI monitoring tools
Java VisualVM
Oracle Mission Control
JConsole
JRE
Class organization with packages
What are packages?
Choosing a package name
Package name examples
Fully qualified class name
Java Class Library
Java Class Library organization
Package overview
Fundamental classes of the java.lang package
The Object class (java.lang.Object)
Important object methods
The String class (java.lang.String)
Primitive wrapper classes (Integer, Long, Short, Char, Float, Double in java.lang)
Autoboxing examples
Exceptions and errors (java.lang.Exception and java.lang.Error)
The Collections API - java.util.ArrayList and java.util.HashMap
ArrayList (java.util.ArrayList)
Commonly used methods of the ArrayList class
ArrayList usage example
HashMap (java.util.HashMap)
Commonly used methods of the HashMap class
HashMap usage example
Preparing your classes for the Collections API
About hashCode()
About equals ()
The hashing mechanism
Running JVM applications on the command line
At least one class must have a static main() method
Required directory structure for class files
Setting ClassPath for a JVM instance
Placing class files inside a JAR archive
Runnable JAR file
Running a program with the java command
Run a project consisting of separate class files
Running a project that is placed inside a runnable JAR file
Other useful parameters of the java command
-D to pass properties and values
-ea to enable assertions
A hands-on example project to run on JVM
A ClassPath example
Eclipse IDE
Downloading Eclipse IDE
Installing Eclipse IDE
Summary
Java
OOP in Java
Defining classes
Class access modifiers
Final class modifier - locking a class
Defining packages
Importing classes
Adding class members - variables and methods
Instance variables
Methods
Modifiers
Protecting class members with access modifiers
Access modifier example
Static modifier - instance variables and class variables
Final modifier - locking a class member
Overloading methods
Constructors and finalizers
Constructors
Finalizers
Extending a class
Overriding methods
Calling constructors of a parent class
Abstract classes
Interfaces
Upcasting and downcasting
Writing Java code
Operators
Conditional checks
The if...else statement
The switch...case statement
POJO
Arrays
Generics and Collections
Loops
The for loop
The normal for loop
The enhanced for loop
The while loop
The do...while loop
Exceptions
Runtime exceptions
Threads
Lambdas
Style guide
Quiz
Summary
Java Programming
Configuring Eclipse IDE
Creating a web service in Java
Creating a new Gradle project in Eclipse IDE
Exploring the generated project
Modifying the Gradle build file
Building the project
Coding the backend class
Backend class business rules
Creating a dummy implementation of the method
Creating the test case class and writing its first unit test
Implementing an input validation check
Writing the second unit test
Implementing the business logic
Creating an executable application task
Creating a web service
Running the web service
Creating Javadoc documentation
Summary
Scala
Installing Scala
Scala's Read-Eval-Print-Loop shell
Functional versus imperative programming
Scala language syntax and rules
Statically typed language
Mutable and immutable variables
Common Scala types
Any class
AnyRef class - reference classes
AnyVal class - value classes
Strings
OOP in Scala
Defining packages and subpackages
Importing members
Defining classes
Instance variables and methods
Instance variables
Instance methods
Access modifiers for class instance members
Constructors
Extending a class
Overriding methods
Overloading methods
Abstract classes
Traits
Singleton objects
Operator overloading
Case classes
Scala's standard library
Generics
Collections
Immutable list
Mutable list
Immutable map
Mutable map
XML processing
Functional programming in Scala
Iterating through collections using functions
The map, filter, and reduce design pattern
Map - transform data
Filter - filter items from a collection or array
Reduce - for performing calculations
Currying
Quiz
Summary
Scala Programming
Scala IDE for the Eclipse plugin
Installing Scala IDE for Eclipse
Switching to the Scala IDE perspective
SBT
Installing SBT
Creating an SBT-based Eclipse IDE project
Creating a new SBT project
Loading the SBTEclipse plugin
Generating a new Eclipse IDE project with SBTEclipse
Importing the generated project in Eclipse IDE
The Scala compiler (scalac)
Creating a singleton object with the main() method
Creating a singleton object that extends the App trait
Creating an Akka project
Adding an Akka dependency to the SBT build file
Updating the Scala IDE project
Akka concepts
Actors
Actor references (ActorRef)
Messages
Dispatchers
Creating our first Akka actor - QuotesHandlerActor
Creating messages
Writing a ScalaTest-based unit test
Implementing a message handler
Creating QuotePrinterActor
The main application
Summary
Clojure
Installing Clojure
Creating a start script
Creating a start script on Windows
Creating a start script on macOS and Linux
Clojure's interactive shell (REPL)
Clojure language
Syntax
Expressions
Defining variables
Defining functions
Data structures
Numeric types
Strings and characters
Collections
Lists
Vectors
Sets
Hash-maps
Iteration over arrays and loops
Conditions
Working with Java classes
Creating simple Java classes with deftype and defrecord
Managing states with agents
Agent example
Style guide
Quiz
Summary
Clojure Programming
The Counterclockwise plugin for Eclipse IDE
Installing the Counterclockwise plugin
Switching to the Java perspective
Leiningen's build tool
Installing Leiningen
Creating executable programs in Clojure
Compiling to class files without Leiningen
Compiling projects with Leiningen
Creating a new Counterclockwise project
Clojure REPL in Eclipse IDE
Updating the project's Clojure version
Adding a dependency
Exploring monads by applying test-driven development
The Luminus web framework
Creating a Luminus project
Importing the project in Counterclockwise
Exploring the Luminus project
Adding a page to the web application
Summary
Kotlin
Installing Kotlin
Launch scripts
Kotlin's REPL interactive shell
Kotlin language fundamentals
Defining local variables
Defining a function
Kotlin's types
Kotlin basic types
Strings
Null safety handling
Option 1 - Adding a conditional check
Option 2 - Using the safe call operator ?.
Option 3 - Using the Elvis operator ?:
Option 4 - Using the !! operator
Conversions
Collections and generics
Loops
OOP in Kotlin
Defining packages
Importing members
Defining classes and constructors
Adding members to classes
Adding functions
The main entry function
Adding properties
Inheritance
Interfaces
Visibility modifiers
Singleton and companion objects
Data classes
Lambdas and inline functions
Procedural programming in Kotlin
Style guide
Quiz
Summary
Kotlin Programming
Kotlin for the Eclipse IDE plugin
Installing the Kotlin plugin for the Eclipse IDE
Switching to Kotlin perspective
Apache Maven
Installing Apache Maven
Downloading a preconfigured Kotlin starter kit
Importing the project in the Eclipse IDE
Exploring the pom.xml build file
Updating the build file in Eclipse
Creating a JavaFX desktop GUI application
Preparing the project
Creating a runnable application
Writing an extension function
Layout panes
Implementing a BorderPane-based layout
Implementing animation
Debugging the program
Summary
Groovy
Installing Groovy
GroovyConsole and GroovyShell
GroovyConsole
GroovyShell
Groovy Language
Object-oriented programming in Groovy
Groovy is fully object oriented
Access modifiers
Adding properties to a class
Optional types
Automatically creating a fully featured POJO
Creating immutable classes
Groovy Development Kit (GDK)
Groovy Strings (GStrings)
Collections
Lists
Maps
Dynamic and static programming
Meta programming
Static programming in Groovy
Quiz
Summary
Groovy Programming
Installing the Groovy Eclipse plugin
Switching to Java perspective
Apache Ivy and IvyDE
Installing Apache IvyDE plugin for Eclipse IDE
Creating and configuring the project
Creating a new Groovy Eclipse project
Creating an ivy.xml file for Ivy
Java Database Connectivity (JDBC)
H2 database
Creating an in-memory database
Generating XML using MarkupBuilder
Generating XML based on SQL
The Vert.x microservice platform
Adding Vert.x dependency to Ivy
Creating the web service
Summary
Other JVM languages
Oracle Nashorn
Embedding Nashorn in JVM-based projects
Running Nashorn
Jython (Python)
Differences between CPython and Jython
Running Jython
JRuby (Ruby)
Ruby on Rails and JRuby
Running JRuby
Frege (Haskell)
Calling Java code from Frege
Running Frege
Ceylon
Ceylon's module system
Running Ceylon
Summary
Quiz Answers
Chapter 3: Java
Chapter 5: Scala
Chapter 7: Clojure
Chapter 9: Kotlin
Chapter 11: Groovy

第1章　垃圾回收概述 1
1.1　Java发展概述 1
1.2　本书常见术语 4
1.3　回收算法概述 6
1.3.1　分代管理算法 7
1.3.2　复制算法 7
1.3.3　标记清除 8
1.3.4　标记压缩 9
1.3.5　算法小结 9
1.4　JVM垃圾回收器概述 9
1.4.1　串行回收 9
1.4.2　并行回收 10
1.4.3　并发标记回收 10
1.4.4　垃圾优先回收 10
第2章　G1的基本概念 14
2.1　分区 14
2.2　G1停顿预测模型 20
2.3　卡表和位图 22
2.4　对象头 24
2.5　内存分配和管理 27
2.6　线程 30
2.6.1　栈帧 32
2.6.2　句柄 34
2.6.3　JVM本地方法栈中的对象 36
2.6.4　Java本地方法栈中的对象 40
2.7　日志解读 40
2.8　参数介绍和调优 41
第3章　G1的对象分配 43
3.1　对象分配概述 43
3.2　快速分配 46
3.3　慢速分配 56
3.3.1　大对象分配 58
3.3.2　最后的分配尝试 60
3.4　G1垃圾回收的时机 61
3.4.1　分配时发生回收 61
3.4.2　外部调用的回收 61
3.5　参数介绍和调优 62
第4章　G1的Ref?ine线程 64
4.1　记忆集 64
4.2　Ref?ine线程的功能及原理 72
4.2.1　抽样线程 72
4.2.2　管理RSet 74
4.2.3　Mutator处理DCQ 78
4.2.4　Ref?ine线程的工作原理 78
4.3　Ref?inement Zone 85
4.4　RSet涉及的写屏障 86
4.5　日志解读 87
4.6　参数介绍和调优 90
第5章　新生代回收 93
5.1　YGC算法概述 93
5.2　YGC代码分析 96
5.2.1　并行任务 96
5.2.2　其他处理 115
5.3　YGC算法演示 116
5.3.1　选择CSet 117
5.3.2　根处理 117
5.3.3　RSet处理 118
5.3.4　复制 119
5.3.5　Redirty 120
5.3.6　释放空间 120
5.4　日志解读 121
5.4.1　YGC日志 121
5.4.2　大对象日志分析 125
5.4.3　对象年龄日志分析 125
5.5　参数介绍和调优 126
第6章　混合回收 129
6.1　并发标记算法详解 130
6.2　并发标记算法的难点 133
6.2.1　三色标记法 133
6.2.2　难点示意图 133
6.2.3　再谈写屏障 135
6.3　G1中混合回收的步骤 141
6.4　混合回收中并发标记处理的线程 145
6.4.1　并发标记线程启动的时机 147
6.4.2　根扫描子阶段 148
6.4.3　并发标记子阶段 152
6.4.4　再标记子阶段 159
6.4.5　清理子阶段 160
6.4.6　启动混合收集 167
6.5　并发标记算法演示 170
6.5.1　初始标记子阶段 171
6.5.2　根扫描子阶段 171
6.5.3　并发标记子阶段 171
6.5.4　再标记子阶段 172
6.5.5　清理子阶段 173
6.6　GC活动图 174
6.7　日志解读 174
6.8　参数优化 178
第7章　Full GC 181
7.1　Evac失败 181
7.2　串行FGC 187
7.2.1　标记活跃对象 188
7.2.2　计算对象的新地址 190
7.2.3　更新引用对象的地址 190
7.2.4　移动对象完成压缩 193
7.2.5　后处理 194
7.3　并行FGC 196
7.3.1　并行标记活跃对象 197
7.3.2　计算对象的新地址 198
7.3.3　更新引用对象的地址 200
7.3.4　移动对象完成压缩 200
7.3.5　后处理 201
7.4　日志解读 201
7.5　参数介绍和调优 202
第8章　G1中的引用处理 203
8.1　引用概述 203
8.2　可回收对象发现 207
8.3　在GC时的处理发现列表 210
8.4　重新激活可达的引用 214
8.5　日志解读 215
8.6　参数介绍和调优 215
第9章　G1的新特性：字符串去重 217
9.1　字符串去重概述 217
9.2　日志解读 220
9.3　参数介绍和调优 222
9.4　字符串去重和String.intern的区别 222
9.5　String.intern中的实现 223
第10章　线程中的安全点 226
10.1　安全点的基本概念 226
10.2　G1并发线程进入安全点 227
10.3　解释线程进入安全点 230
10.4　编译线程进入安全点 230
10.5　正在执行本地代码的线程进入安全点 233
10.6　安全点小结 236
10.7　日志分析 236
10.8　参数介绍和调优 238
第11章　垃圾回收器的选择 241
11.1　如何衡量垃圾回收器 241
11.2　G1调优的方向 243
第12章　新一代垃圾回收器 247
12.1　Shenandoah 247
12.2　ZGC 258
附录A　编译调试JVM 262
附录B　本地内存跟踪 272
附录C　阅读JVM需要了解的C++知识 276


JVM 与 Linux 的内存关系详解
Java技术栈  3天前


来源：美团技术团队

在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。

从表面上，物理内存应该是足够使用的；但实际运行的情况是，会发生大量使用SWAP(说明物理内存不够使用 了)，如下图所示。由于SWAP和GC同时发生会致使JVM严重卡顿，所以我们要追问：内存究竟去哪儿了？





要分析这个问题，理解JVM和操作系统之间的内存关系非常重要。接下来主要就Linux与JVM之间的内存关系进行一些分析。

一、Linux与进程内存模型

JVM以一个进程（Process）的身份运行在Linux系统上，了解Linux与进程的内存关系，是理解JVM与Linux内存的关系的基础。下图给出了硬件、系统、进程三个层面的内存之间的概要关系。



从硬件上看，Linux系统的内存空间由两个部分构成：物理内存和SWAP（位于磁盘）。物理内存是Linux活动时使用的主要内存区域；当物理内存不够使用时，Linux会把一部分暂时不用的内存数据放到磁盘上的SWAP中去，以便腾出更多的可用内存空间；而当需要使用位于SWAP的数据时，必须 先将其换回到内存中。JVM运行时区域详解，推荐大家看下。

从Linux系统上看，除了引导系统的BIN区，整个内存空间主要被分成两个部分：内核内存（Kernel space）、用户内存（User space）。

内核内存是Linux自身使用的内存空间，主要提供给程序调度、内存分配、连接硬件资源等程序逻辑使用。

用户内存是提供给各个进程主要空间，Linux给各个进程提供相同的虚拟内存空间；这使得进程之间相互独立，互不干扰。实现的方法是采用虚拟内存技术：给每一个进程一定虚拟内存空间，而只有当虚拟内存实 际被使用时，才分配物理内存。

如下图所示，对于32的Linux系统来说，一般将0～3G的虚拟内存空间分配做为用户空间，将3～4G的虚拟内存空间分配 为内核空间；64位系统的划分情况是类似的。



从进程的角度来看，进程能直接访问的用户内存（虚拟内存空间）被划分为5个部分：代码区、数据区、堆区、栈区、未使用区。

代码区中存放应用程序的机器代码，运行过程中代码不能被修改，具有只读和固定大小的特点。

数据区中存放了应用程序中的全局数据，静态数据和一些常量字符串等，其大小也是固定的。

堆是运行时程序动态申请的空间，属于程序运行时直接申请、释放的内存资源。

栈区用来存放函数的传入参数、临时变量，以及返回地址等数据。

未使用区是分配新内 存空间的预备区域。

二、进程与JVM内存空间

JVM本质就是一个进程，因此其内存空间（也称之为运行时数据区，注意与JMM的区别）也有进程的一般特点。深入浅出 Java 中 JVM 内存管理，这篇参考下。

但是，JVM又不是一个普通的进程，其在内存空间上有许多崭新的特点，主要原因有两 个：

1.JVM将许多本来属于操作系统管理范畴的东西，移植到了JVM内部，目的在于减少系统调用的次数；

2. Java NIO，目的在于减少用于读写IO的系统调用的开销。JVM进程与普通进程内存模型比较如下图:



需要说明的是，这个模型的并不是JVM内存使用的精确模型，更侧重于从操作系统的角度而省略了一些JVM的内部细节（尽管也很重要）。下面从用户内存和内核内存两个方面讲解JVM进程的内存特点。

1.用户内存
上图特别强调了JVM进程模型的代码区和数据区指的是JVM自身的，而非Java程序的。普通进程栈区，在JVM一般仅仅用做线程栈。JVM的堆区和普通进程的差别是最大的，下面具体详细说明：

首先是永久代。永久代本质上是Java程序的代码区和数据区。Java程序中类（class），会被加载到整个区域的不同数据结构中去，包括常量池、域、方法数据、方法体、构造函数、以及类中的专用方法、实例初始化、接口初始化等。这个区域对于操作系统来说，是堆的一个部分；而对于Java程序来 说，这是容纳程序本身及静态资源的空间，使得JVM能够解释执行Java程序。

其次是新生代和老年代。新生代和老年代才是Java程序真正使用的堆空间，主要用于内存对象的存储；但是其管理方式和普通进程有本质的区别。

普通进程在运行时给内存对象分配空间时，比如C++执行new操作时，会触发一次分配内存空间的系统调用，由操作系统的线程根据对象的大小分配好空间后返 回；同时，程序释放对象时，比如C++执行delete操作时，也会触发一次系统调用，通知操作系统对象所占用的空间已经可以回收。

JVM对内存的使用和一般进程不同。JVM向操作系统申请一整段内存区域（具体大小可以在JVM参数调节）作为Java程序的堆（分为新生代和老年代）；当Java程序申请内存空间，比如执行new操作，JVM将在这段空间中按所需大小分配给Java程序，并且Java程序不负责通知JVM何时可以释放这 个对象的空间，垃圾对象内存空间的回收由JVM进行。

JVM的内存管理方式的优点是显而易见的，包括：第一，减少系统调用的次数，JVM在给Java程序分配内存空间时不需要操作系统干预，仅仅在 Java堆大小变化时需要向操作系统申请内存或通知回收，而普通程序每次内存空间的分配回收都需要系统调用参与；第二，减少内存泄漏，普通程序没有（或者 没有及时）通知操作系统内存空间的释放是内存泄漏的重要原因之一，而由JVM统一管理，可以避免程序员带来的内存泄漏问题。

最后是未使用区，未使用区是分配新内存空间的预备区域。对于普通进程来说，这个区域被可用于堆和栈空间的申请及释放，每次堆内存分配都会使用这个区 域，因此大小变动频繁；对于JVM进程来说，调整堆大小及线程栈时会使用该区域，而堆大小一般较少调整，因此大小相对稳定。操作系统会动态调整这个区域的 大小，并且这个区域通常并没有被分配实际的物理内存，只是允许进程在这个区域申请堆或栈空间。

2.内核内存
应用程序通常不直接和内核内存打交道，内核内存由操作系统进行管理和使用；不过随着Linux对性能的关注及改进，一些新的特性使得应用程序可以使 用内核内存，或者是映射到内核空间。Java NIO正是在这种背景下诞生的，其充分利用了Linux系统的新特性，提升了Java程序的IO性能。



上图给出了Java NIO使用的内核内存在linux系统中的分布情况。nio buffer主要包括：nio使用各种channel时所使用的ByteBuffer、Java程序主动使用 ByteBuffer.allocateDirector申请分配的Buffer。

而在PageCache里面，nio使用的内存主要包 括：FileChannel.map方式打开文件占用mapped、FileChannel.transferTo和 FileChannel.transferFrom所需要的Cache（图中标示 nio file）。

通过JMX可以监控到NIO Buffer和 mapped 的使用情况，如下图所示。不过，FileChannel的实现是通过系统调用使用原生的PageCache，过程对于Java是透明的，无法监控到这部分内存的使用大小。



Linux和Java NIO在内核内存上开辟空间给程序使用，主要是减少不要的复制，以减少IO操作系统调用的开销。例如，将磁盘文件的数据发送网卡，使用普通方法和NIO时，数据流动比较下图所示：



将数据在内核内存和用户内存之间拷贝是比较消耗资源和时间的事情，而从上图我们可以看到，通过NIO的方式减少了2次内核内存和用户内存之间的数据拷贝。这是Java NIO高性能的重要机制之一（另一个是异步非阻塞）。

从上面可以看出，内核内存对于Java程序性能也非常重要，因此，在划分系统内存使用时候，一定要给内核留出一定可用空间。

三、案例分析
1.内存分配问题
通过上面的分析，省略比较小的区域，可以总结JVM占用的内存：
JVM内存 ≈ Java永久代 ＋ Java堆(新生代和老年代) ＋ 线程栈＋ Java NIO

回到文章开头提出的问题，原来的内存分配是：6g(java堆) ＋ 600m(监控) ＋ 800m(系统)，剩余大约600m内存未分配。

现在分析这600m内存的分配情况：

Linux保留大约200m，这部分是Linux正常运行的需要，

Java服务的线程数量是160个，JVM默认的线程栈大小是1m，因此使用160m内存，

Java NIO buffer，通过JMX查到最多占用了200m，

Java服务使用NIO大量读写文件，需要使用PageCache，正如前面分析，这个暂时不好定量估算大小。

前三项加起来已经560m，因此可以断定Linux物理内存不够使用。

细心的人会发现，引言中给出两个服务器，一个SWAP最多占用了2.16g，另外一个SWAP最多占用了871m；但是，似乎我们的内存缺口没有那么大。事实上，这是由于SWAP和GC同时进行造成的，从下图可以看到，SWAP的使用和长时间的GC在同一时刻发生。





SWAP和GC同时发生会导致GC时间很长，JVM严重卡顿，极端的情况下会导致服务崩溃。原因如下：JVM进行GC时，时需要对相应堆分区的已用 内存进行遍历；假如GC的时候，有堆的一部分内容被交换到SWAP中，遍历到这部分的时候就需要将其交换回内存，同时由于内存空间不足，就需要把内存中堆 的另外一部分换到SWAP中去；于是在遍历堆分区的过程中，(极端情况下)会把整个堆分区轮流往SWAP写一遍。Linux对SWAP的回收是滞后的，我 们就会看到大量SWAP占用。上述问题，可以通过减少堆大小，或者增加物理内存解决。

因此，我们得出一个结论：部署Java服务的Linux系统，在内存分配上，需要避免SWAP的使用；具体如何分配需要综合考虑不同场景下JVM对Java永久代 、Java堆(新生代和老年代)、线程栈、Java NIO所使用内存的需求。

2.内存泄漏问题
另一个案例是，8g内存的服务器，Linux使用800m，监控进程使用600m，堆大小设置4g；系统可用内存有2.5g左右，但是也发生了大量的SWAP占用。

分析这个问题如下：

在这个场景中， Java永久代 、Java堆(新生代和老年代)、线程栈所用内存基本是固定的，因此，占用内存过多的原因就定位在Java NIO上。

根据前面的模型，Java NIO使用的内存主要分布在Linux内核内存的System区和PageCache区。查看监控的记录，如下图，我们可以看到发生SWAP之前，也就是 物理内存不够使用的时候，PageCache急剧缩小。因此，可以定位在System区的Java NIO Buffer发生内存泄漏。






由于NIO的DirectByteBuffer需要在GC的后期被回收，因此连续申请DirectByteBuffer的程序，通常需要调用 System.gc()，避免长时间不发生FullGC导致引用在old区的DirectByteBuffer内存泄漏。分析到此，可以推断有两种可能的 原因：第一，Java程序没有在必要的时候调用System.gc()；第二，System.gc()被禁用。

最后是要排查JVM启动参数和Java程序的DirectByteBuffer使用情况。在本例中，查看JVM启动参数，发现启用了-XX:+DisableExplicitGC导致System.gc()被禁用。

四、总结

本文详细分析了Linux与JVM的内存关系，比较了一般进程与JVM进程使用内存的异同点，理解这些特性将对Linux系统内存分配、JVM调优、Java程序优化有帮助。限于篇幅关系仅仅列举两个案例，希望起到抛砖引玉的作用。

关注Java技术栈微信公众号，在后台回复关键字：Java，可以获取更多栈长整理的Java技术干货。

最近干货分享



194. 说一下 jvm 的主要组成部分？及其作用？

类加载器（ClassLoader）

运行时数据区（Runtime Data Area）

执行引擎（Execution Engine）

本地库接口（Native Interface）


组件的作用： 首先通过类加载器（ClassLoader）会把 Java 代码转换成字节码，运行时数据区（Runtime Data Area）再把字节码加载到内存中，而字节码文件只是 JVM 的一套指令集规范，并不能直接交个底层操作系统去执行，因此需要特定的命令解析器执行引擎（Execution Engine），将字节码翻译成底层系统指令，再交由 CPU 去执行，而这个过程中需要调用其他语言的本地库接口（Native Interface）来实现整个程序的功能。

195. 说一下 jvm 运行时数据区？

程序计数器

虚拟机栈

本地方法栈

堆

方法区



有的区域随着虚拟机进程的启动而存在，有的区域则依赖用户进程的启动和结束而创建和销毁。





196. 说一下堆栈的区别？

1. 栈内存存储的是局部变量而堆内存存储的是实体；

2. 栈内存的更新速度要快于堆内存，因为局部变量的生命周期很短；

3. 栈内存存放的变量生命周期一旦结束就会被释放，而堆内存存放的实体会被垃圾回收机制不定时的回收。

197. 队列和栈是什么？有什么区别？

队列和栈都是被用来预存储数据的。

队列允许先进先出检索元素，但也有例外的情况，Deque 接口允许从两端检索元素。

栈和队列很相似，但它运行对元素进行后进先出进行检索。

198. 什么是双亲委派模型？

在介绍双亲委派模型之前先说下类加载器。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立在 JVM 中的唯一性，每一个类加载器，都有一个独立的类名称空间。类加载器就是根据指定全限定名称将 class 文件加载到 JVM 内存，然后再转化为 class 对象。



类加载器分类：



启动类加载器（Bootstrap ClassLoader），是虚拟机自身的一部分，用来加载Java_HOME/lib/目录中的，或者被 -Xbootclasspath 参数所指定的路径中并且被虚拟机识别的类库；

其他类加载器：

扩展类加载器（Extension ClassLoader）：负责加载<java_home style="box-sizing: border-box; -webkit-tap-highlight-color: transparent; text-size-adjust: none; -webkit-font-smoothing: antialiased; outline: 0px !important;">\lib\ext目录或Java. ext. dirs系统变量指定的路径中的所有类库；</java_home>

应用程序类加载器（Application ClassLoader）。负责加载用户类路径（classpath）上的指定类库，我们可以直接使用这个类加载器。一般情况，如果我们没有自定义类加载器默认就是用这个加载器。



双亲委派模型：如果一个类加载器收到了类加载的请求，它首先不会自己去加载这个类，而是把这个请求委派给父类加载器去完成，每一层的类加载器都是如此，这样所有的加载请求都会被传送到顶层的启动类加载器中，只有当父加载无法完成加载请求（它的搜索范围中没找到所需的类）时，子加载器才会尝试去加载类。

199. 说一下类加载的执行过程？

类加载分为以下 5 个步骤：



加载：根据查找路径找到相应的 class 文件然后导入；

检查：检查加载的 class 文件的正确性；

准备：给类中的静态变量分配内存空间；

解析：虚拟机将常量池中的符号引用替换成直接引用的过程。符号引用就理解为一个标示，而在直接引用直接指向内存中的地址；

初始化：对静态变量和静态代码块执行初始化工作。

200. 怎么判断对象是否可以被回收？

一般有两种方法来判断：



引用计数器：为每个对象创建一个引用计数，有对象引用时计数器 +1，引用被释放时计数 -1，当计数器为 0 时就可以被回收。它有一个缺点不能解决循环引用的问题；

可达性分析：从 GC Roots 开始向下搜索，搜索所走过的路径称为引用链。当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是可以被回收的。

201. java 中都有哪些引用类型？

强引用

软引用

弱引用

虚引用（幽灵引用/幻影引用）

202. 说一下 jvm 有哪些垃圾回收算法？

标记-清除算法

标记-整理算法

复制算法

分代算法

203. 说一下 jvm 有哪些垃圾回收器？

Serial：最早的单线程串行垃圾回收器。

Serial Old：Serial 垃圾回收器的老年版本，同样也是单线程的，可以作为 CMS 垃圾回收器的备选预案。

ParNew：是 Serial 的多线程版本。

Parallel 和 ParNew 收集器类似是多线程的，但 Parallel 是吞吐量优先的收集器，可以牺牲等待时间换取系统的吞吐量。

Parallel Old 是 Parallel 老生代版本，Parallel 使用的是复制的内存回收算法，Parallel Old 使用的是标记-整理的内存回收算法。

CMS：一种以获得最短停顿时间为目标的收集器，非常适用 B/S 系统。

G1：一种兼顾吞吐量和停顿时间的 GC 实现，是 JDK 9 以后的默认 GC 选项。

204. 详细介绍一下 CMS 垃圾回收器？

CMS 是英文 Concurrent Mark-Sweep 的简称，是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。在启动 JVM 的参数加上“-XX:+UseConcMarkSweepGC”来指定使用 CMS 垃圾回收器。



CMS 使用的是标记-清除的算法实现的，所以在 gc 的时候回产生大量的内存碎片，当剩余内存不能满足程序运行要求时，系统将会出现 Concurrent Mode Failure，临时 CMS 会采用 Serial Old 回收器进行垃圾清除，此时的性能将会被降低。

205.新生代垃圾回收器和老生代垃圾回收器都有哪些？有什么区别？

新生代回收器：Serial、ParNew、Parallel Scavenge

老年代回收器：Serial Old、Parallel Old、CMS

整堆回收器：G1



新生代垃圾回收器一般采用的是复制算法，复制算法的优点是效率高，缺点是内存利用率低；老年代回收器一般采用的是标记-整理的算法进行垃圾回收。

206. 简述分代垃圾回收器是怎么工作的？

分代回收器有两个分区：老生代和新生代，新生代默认的空间占比总空间的 1/3，老生代的默认占比是 2/3。



新生代使用的是复制算法，新生代里有 3 个分区：Eden、To Survivor、From Survivor，它们的默认占比是 8:1:1，它的执行流程如下：



把 Eden + From Survivor 存活的对象放入 To Survivor 区；

清空 Eden 和 From Survivor 分区；

From Survivor 和 To Survivor 分区交换，From Survivor 变 To Survivor，To Survivor 变 From Survivor。



每次在 From Survivor 到 To Survivor 移动时都存活的对象，年龄就 +1，当年龄到达 15（默认配置是 15）时，升级为老生代。大对象也会直接进入老生代。


老生代当空间占用到达某个值之后就会触发全局垃圾收回，一般使用标记整理的执行算法。以上这些循环往复就构成了整个分代垃圾回收的整体执行流程。

207. 说一下 jvm 调优的工具？

JDK 自带了很多监控工具，都位于 JDK 的 bin 目录下，其中最常用的是 jconsole 和 jvisualvm 这两款视图监控工具。


jconsole：用于对 JVM 中的内存、线程和类等进行监控；

jvisualvm：JDK 自带的全能分析工具，可以分析：内存快照、线程快照、程序死锁、监控内存的变化、gc 变化等。

208. 常用的 jvm 调优的参数都有哪些？

-Xms2g：初始化推大小为 2g；

-Xmx2g：堆最大内存为 2g；

-XX:NewRatio=4：设置年轻的和老年代的内存比例为 1:4；

-XX:SurvivorRatio=8：设置新生代 Eden 和 Survivor 比例为 8:2；

–XX:+UseParNewGC：指定使用 ParNew + Serial Old 垃圾回收器组合；

-XX:+UseParallelOldGC：指定使用 ParNew + ParNew Old 垃圾回收器组合；

-XX:+UseConcMarkSweepGC：指定使用 CMS + Serial Old 垃圾回收器组合；

-XX:+PrintGC：开启打印 gc 信息；

-XX:+PrintGCDetails：打印 gc 详细信息。

=============
最近在调研MAT和VisualVM源码实现，遇到一个可疑问题，两者计算出来的对象大小不一致，才有了这样疑惑。

一个Java对象到底占用多大内存？



为了复现这个问题，准备了4个最简单类：

class
 AAAAA
{}



class
 BBBBB
{


int
 a
=

1
;

}



class
 CCCCC
{


long
 a
=

1L
;

}



class
 DDDDD
{


String
 s
=

"hello"
;

}

当然了，再来个主函数：

final

List
<
AAAAA
>
 aaa
=

new

ArrayList
<>(
100000
);

final

List
<
BBBBB
>
 bbb
=

new

ArrayList
<>(
100000
);

final

List
<
CCCCC
>
 ccc
=

new

ArrayList
<>(
100000
);

final

List
<
DDDDD
>
 ddd
=

new

ArrayList
<>(
100000
);

for

(
int
 i
=

0
;
 i
<

100000
;
 i
++)

{

    aaa
.
add
(
new
 AAAAA
());

    bbb
.
add
(
new
 BBBBB
());

    ccc
.
add
(
new
 CCCCC
());

    ddd
.
add
(
new
 DDDDD
());

}

本地的执行环境是64位的JDK8，且使用默认的启动参数，运行之后通过 jmap-dump命令生成dump文件，分别用MAT和VisualVM打开。

MAT

通过MAT打开，可以发现ABD对象大小都是16字节，而C对象大小为24字节

VisualVM

通过Vis打开，可以发现其显示的大小和MAT有蛮大的差别。



好奇怪，哪个是对的？
要回答这个问题，首先得清楚的知道JVM中对象的内存布局。

在Hotspot中，一个对象包含3个部分：对象头、实例数据和对齐填充。

对象头
这里不讲对象头是个什么东西，感兴趣的同学可以看我的其它文章。
对象头的大小一般和系统的位数有关，也和启动参数 UseCompressedOops有关：

32位系统，占用 8 字节

64位系统，开启 UseCompressedOops时，占用 12 字节，否则是16字节

实例数据
原生类型的内存占用情况如下：

boolean 1

byte 1

short 2

char 2

int 4

float 4

long 8

double 8

引用类型的内存占用和系统位数以及启动参数 UseCompressedOops有关

32位系统占4字节

64位系统，开启 UseCompressedOops时，占用4字节，否则是8字节

对齐填充
在Hotspot中，为了更加容易的管理内存，一般会使用8字节进行对齐。

意思是每次分配的内存大小一定是8的倍数，如果对象头+实例数据的值不是8的倍数，那么会重新计算一个较大值，进行分配。

结果
有了对象各部分的内存占用大小，可以很轻松的计算出ABCD各对象在64位系统，且开启 UseCompressedOops参数时的大小。

A对象只包含一个对象头，大小占12字节，不是8的倍数，需要4字节进行填充，一共占16字节

B对象包含一个对象头和int类型，12+4=16，正好是8的倍数，不需要填充。

C对象包含一个对象头和long类型，12+8=20，不是8的倍数，需要4个字节进行填充，占24字节

D对象包含一个对象头和引用类型，12+4=16，正好是8的倍数，不需要填充。

可以得出，VisualVM的显示结果有点问题，主要因为以下两点：

首先，没有考虑是否开启 UseCompressedOops

其次，没有考虑内存对齐填充的情况

感兴趣的同学，可以动手实践一下，这样可以加深对象内存布局的理解。

经过这段时间对MAT和VisualVM的源码研究，发现MAT的功能不是强大一点点，建议大家以后尽量使用MAT。

==================================================

阿里面试官：字符串在JVM中如何存放？90%的人就真的只回答在哪里存放
阿杜的世界  石杉的架构笔记  昨天
点击上方石杉的架构笔记，右上角选择“设为星标”

每日早8点半，技术文章准时送上

公众号后台回复“学习”，获取作者独家秘制精品资料





往期文章

BAT 面试官是如何360°无死角考察候选人的（上篇）

每秒上万并发下的Spring Cloud参数优化实战

分布式事务如何保障实际生产中99.99%高可用

记一位朋友斩获 BAT 技术专家Offer的面试经历

亿级流量架构系列之如何支撑百亿级数据的存储与计算


本文来源：javaadu



目录：

一道面试题的引出

案例分析

intern 源码分析

总结



1. 一道面试题的引出

在面试BAT这种一线大厂时，如果面试官问道：字符串在 JVM 中如何存放？大多数人能顺利的给出如下答案：



字符串对象在JVM中可能有两个存放的位置：字符串常量池或堆内存。



使用常量字符串初始化的字符串对象，它的值存放在字符串常量池中；


使用字符串构造方法创建的字符串对象，它的值存放在堆内存中；



但是如果能针对上述回答，做进一步扩展，会给你的面试表现加分不少，让你从一大波候选人中脱颖而出。下面就一起来分析一下。



首先来看，String提供了一个API, java.lang.String.intern()，这个API可以手动将一个字符串对象的值转移到字符串常量池中



在1.7之前，字符串常量池是在PermGen区域，这个区域的大小是固定的，不能在运行时根据需要扩大，也不能被垃圾收集器回收，因此如果程序中有太多的字符串调用了intern方法的话，就可能造成OOM。



在1.7以后，字符串常量池移到了堆内存中，并且可以被垃圾收集器回收，这个改动降低了字符串常量池OOM的风险。



2. 案例分析


验证代码：

public

class

StringTest
 {




public

static

void
 main(
String
[] args) {


String
 s1 =
"javaadu"
;


String
 s2 =
"javaadu"
;


String
 s3 =
new

String
(
"javaadu"
);


System
.
out
.println(s1 == s2);
//true


System
.
out
.println(s1 == s3);
//false




String
 s4 = s3.intern();


System
.
out
.println(s1 == s4);
//true

    }

}


3. intern源码分析
我们来看intern方法的实现，intern方法的底层是一个native方法，在Hotspot JVM里字符串常量池它的逻辑在注释里写得很清楚：



如果常量池中有这个字符串常量，就直接返回，否则将该字符串对象的值存入常量池，再返回。



这里以Openjdk1.8的源码为例，跟下intern方法的底层实现，String.java文件对应的C文件是String.c：

JNIEXPORT jobject JNICALL

Java_java_lang_String_intern
(
JNIEnv

*
env
,
 jobject
this
)

{


return
 JVM_InternString
(
env
,

this
);

}

JVM_InternString这个方法的定义在jvm.h，实现在jvm.cpp中，在JVM中，Java世界和C++世界的连接层就是jvm.h和jvm.cpp这两文件。

JVM_ENTRY
(
jstring
,
 JVM_InternString
(
JNIEnv

*
env
,
 jstring str
))


JVMWrapper
(
"JVM_InternString"
);


JvmtiVMObjectAllocEventCollector
 oam
;


if

(
str
==
 NULL
)

return
 NULL
;

 oop
string

=

JNIHandles
::
resolve_non_null
(
str
);

 oop result
=

StringTable
::
intern
(
string
,
 CHECK_NULL
);


return

(
jstring
)

JNIHandles
::
make_local
(
env
,
 result
);

JVM_END

可以看出，字符串常量池在JVM内部就是一个HashTable，也就是上面代码中的StringTable。

从 StringTable::intern方法跟下去，可以发现：如果找到了这次操作的字符串，就直接返回found_string；如果没有找到，就将当前的字符串加入到HashTable中，然后再返回。



4. 总结
在Java应用恰当得使用String.intern()方法有助于节省内存空间，但是在使用的时候，也需要注意，因为StringTable的大小是固定的，如果常量池中的字符串过多，会影响程序运行效率。

====================