摘要:堆内存使用分析,垃圾收集器日志解读重要的东东在中,对象实例都是在堆上创建。机制是由提供,用来清理需要清除的对象,回收堆内存。在中,是由一个被称为垃圾回收器的守护线程执行的。
堆内存使用分析,垃圾收集器 GC 日志解读 重要的东东
在Java中,对象实例都是在堆上创建。一些类信息,常量,静态变量等存储在方法区。堆和方法区都是线程共享的。
GC机制是由JVM提供,用来清理需要清除的对象,回收堆内存。
GC机制将Java程序员从内存管理中解放了出来,可以更关注于业务逻辑。
在Java中,GC是由一个被称为垃圾回收器的守护线程执行的。
在从内存回收一个对象之前会调用对象的finalize()方法。
作为一个Java开发者不能强制JVM执行GC;GC的触发由JVM依据堆内存的大小来决定。
System.gc()和Runtime.gc()会向JVM发送执行GC的请求,但是JVM不保证一定会执行GC。
如果堆没有内存创建新的对象了,会抛出OutOfMemoryError。
什么样的对象会被GC回收?在垃圾收集器进行回收前,第一件事就是确定这些对象哪些还存活,哪些已经死去。
点击 查看 我的另一篇文章 《深入理解Java虚拟机》(三)垃圾收集器与内存分配策略
测试环境系统
Microsoft Windows [版本 10.0.14393]
JDK
java version "1.8.0_112" Java(TM) SE Runtime Environment (build 1.8.0_112-b15) Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)
测试工具
IntelliJ IDEA 2017.2示例代码
这里我们来通过一个小程序进行一下堆内存分析,代码如下:
package net.penglei.test; public class HeapTest { private static final int _1M = 1024 * 1024; public static void main(String[] args) throws InterruptedException { byte[] byte1 = new byte[2 * _1M]; byte[] byte2 = new byte[2 * _1M]; byte[] byte3 = new byte[2 * _1M]; byte[] byte4 = new byte[2 * _1M]; byte[] byte5 = new byte[2 * _1M]; byte[] byte6 = new byte[5 * _1M]; byte[] byte7 = new byte[2 * _1M]; } }设置JVM 参数配置
-Xms20m -Xmx20m -Xmn10m -verbose:gc -XX:+PrintGCDetails #输出详细GC日志模式 -XX:+PrintTenuringDistribution #输出每次minor GC后新的存活周期的阈值 -XX:+PrintGCTimeStamps #输出gc的触发时间
我的 IntelliJ IDEA 配置
查看程序进程,堆详情查看 jps -l 看进程,通过 jmap -heap pid 查看堆的概要信息
$ jps -l 5636 net.penglei.test.HeapTest堆配置
$ jmap -heap 5636 Attaching to process ID 5636, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.112-b15 using thread-local object allocation. Parallel GC with 8 thread(s) Heap Configuration: MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 #GC后如果发现空闲堆内存占到整个预估堆内存的N%(百分比) MaxHeapSize = 20971520 (20.0MB) # 堆最大空闲 jvm参数 -Xms20m NewSize = 10485760 (10.0MB) # 年轻代空间 jvm参数 -Xmn10m MaxNewSize = 10485760 (10.0MB) # 年轻代最大空间 OldSize = 10485760 (10.0MB) # 老年代空间 =(等于)堆内存大小 -(减去)年轻代大小 NewRatio = 2 SurvivorRatio = 8 # 年轻代内存又被分成三部分 Eden 空间 80% 而From Survivor 空间 和 To Survivor空间 分别占用10% MetaspaceSize = 21807104 (20.796875MB) # 设置元空间的最大值 jvm参数 -XX:MaxMetaspaceSize CompressedClassSpaceSize = 1073741824 (1024.0MB) # 类指针压缩空间大小, 默认为1G MaxMetaspaceSize = 17592186044415 MB # 是分配给类元数据空间的最大值 G1HeapRegionSize = 0 (0.0MB) # G1区块的大小, 取值为1M至32M. 其取值是要根据最小Heap大小划分出2048个区块 ...执行完 byte3
byte[] byte3 = new byte[2 * _1M];
$ jmap -heap 5636 ... Heap Usage: PS Young Generation Eden Space: capacity = 8388608 (8.0MB) used = 7635080 (7.281379699707031MB) free = 753528 (0.7186203002929688MB) 91.01724624633789% used From Space: capacity = 1048576 (1.0MB) used = 0 (0.0MB) free = 1048576 (1.0MB) 0.0% used To Space: capacity = 1048576 (1.0MB) used = 0 (0.0MB) free = 1048576 (1.0MB) 0.0% used PS Old Generation capacity = 10485760 (10.0MB) used = 0 (0.0MB) free = 10485760 (10.0MB) 0.0% used 1628 interned Strings occupying 148560 bytes.
数据区块 | 堆总容量 | 使用容量 | 剩余容量 | 使用占比 |
---|---|---|---|---|
年轻代 | 8.0MB | 7.28MB | 0.71MB | 91.0% |
幸存者0 | 1.0MB | 0.00MB | 1.0MB | 0.0% |
幸存者1 | 1.0MB | 0.00MB | 1.0MB | 0.0% |
老年代 | 10.0MB | 0.00MB | 10.MB | 0.0% |
PS Young Generation 年轻代空间,使用量达到 91.0%,内存剩余0.71MB,当下次执行byte4(占用年轻代2M内存),会触发Eden Space 空间(年轻代) Minor GC (年轻代垃圾收集)。
PS Old Generation 老年代空间,使用量达到 0.00%,内存剩余10.MB,当下次执行 byte4(占用年轻代2M内存),上面 Eden Space 空间(年轻代) Minor GC (年轻代垃圾收集),会老年代占用一部分内存。
执行完 byte4byte[] byte4 = new byte[2 * _1M]控制台打印的GC日志
641.638: [GC (Allocation Failure) Desired survivor size 1048576 bytes, new threshold 7 (max 15) [PSYoungGen: 7456K->728K(9216K)] 7456K->6880K(19456K), 0.0036244 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 641.642: [Full GC (Ergonomics) [PSYoungGen: 728K->0K(9216K)] [ParOldGen: 6152K->6700K(10240K)] 6880K->6700K(19456K), [Metaspace: 2848K->2848K(1056768K)], 0.0068164 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]GC日志分块图解 ps(画的不好)
$ jmap -heap 5636 ... Heap Usage: PS Young Generation Eden Space: capacity = 8388608 (8.0MB) used = 2097168 (2.0000152587890625MB) free = 6291440 (5.9999847412109375MB) 25.00019073486328% used From Space: capacity = 1048576 (1.0MB) used = 0 (0.0MB) free = 1048576 (1.0MB) 0.0% used To Space: capacity = 1048576 (1.0MB) used = 0 (0.0MB) free = 1048576 (1.0MB) 0.0% used PS Old Generation capacity = 10485760 (10.0MB) used = 6861768 (6.543891906738281MB) free = 3623992 (3.4561080932617188MB) 65.43891906738281% used 1556 interned Strings occupying 143760 bytes.GC日志详细分析
641.638: [GC (Allocation Failure) Desired survivor size 1048576 bytes, new threshold 7 (max 15) [PSYoungGen: 7456K->728K(9216K)] 7456K->6880K(19456K), 0.0036244 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Parallel Scavenge 是年轻代 GC 收集器
641.638: [GC (Allocation Failure)
1641.638:是本次GC发生的时间,从jvm启动起开始计时,单位为秒。这是一次Minor GC(年轻代垃圾收集),Minor GC 非常频繁,回收速度快。
Desired survivor size 1048576 bytes, new threshold 7 (max 15)
期望的幸存者大小1048576字节,新的存活周期的阈值为7(max 15)。
[PSYoungGen: 7456K->728K(9216K)]
格式为:[PSYoungGen: a->b(c)]
年轻代使用的是多线程垃圾收集器 Parallel Scavenge(新生代收集器,一般采用复制算法,并行的多线程收集器)
PSYoungGen,表示 GC发生在年轻代。
a 为GC前年轻代已占用空间,年轻代又细分为一个Eden 空间和From Survivor 空间 和 To Survivor空间。
b 为 Minor GC之后Eden空间GC后年轻代已占用空间 或者Survivor中已被占用的空间。
c 括号里的c表示整个年轻代的大小。
7456K->6880K(19456K)
格式为:x->y(z)
x 表示GC前堆的已占用空间,
y 表示GC后堆已占用空间,
z 表示堆的总大小。
, 0.0036244 secs]
表示本次GC所消耗的时间。
[Times: user=0.00 sys=0.00, real=0.00 secs]
提供cpu使用及时间消耗,user是用户态消耗的cpu时间,sys是系统态消耗的cpu时间,real是实际的消耗时间。
老年代占用内存空间 计算方式
老年代的内存大小 = (等于) 堆内存总大小 - (减去)年轻代内存大小。
此例中就是19456K - 9216K = 10240K
Parallel Old 是Parallel Scavenge 收集器的老年代版本
641.642: [Full GC (Ergonomics) [PSYoungGen: 728K->0K(9216K)] [ParOldGen: 6152K->6700K(10240K)] 6880K->6700K(19456K), [Metaspace: 2848K->2848K(1056768K)], 0.0068164 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
641.642: [Full GC (Ergonomics)
老年代GC 又称为Major GC,经常会伴随一次Minor GC(年轻代垃圾回收)速度比较慢
641.642:是本次GC发生的时间,从jvm启动起开始计时,单位为秒。[Full GC (Ergonomics) ,表示执行全局垃圾回收
[PSYoungGen: 728K->0K(9216K)]
格式为:[PSYoungGen: a->b(c)]
年轻代使用的是多线程垃圾收集器 Parallel Scavenge(新生代收集器,一般采用复制算法,并行的多线程收集器)
PSYoungGen,表示 GC发生在年轻代。
a 为GC前年轻代已占用空间,年轻代又细分为一个Eden 空间和From Survivor 空间 和 To Survivor空间。
b 为 Minor GC之后Eden空间GC后年轻代已占用空间 或者Survivor中已被占用的空间。
c 括号里的c表示整个年轻代的大小。
[ParOldGen: 6152K->6700K(10240K)]
格式为:[ParOldGen: x->y(z)]
老年代GC,使用 Parallel Old收集器,是Parallel Scavenge收集器的老年代版本,一搬采用多线程和“标记-整理”算法
ParOldGen 表示 GC 发生在老年代。
x 为GC前老年代已占用空间
y 为GC后老年代已占用空间
括号里的 z 为整个老年代的大小
6880K->6700K(19456K)
格式为:e->f(g)]
e 为GC前堆堆内存占用,
f 为GC后堆堆内存占用,
括号里的 g 为JVM整个堆的总大小。
[Metaspace: 2848K->2848K(1056768K)]
java8 特性是 把永久代 (Permanent Generation (PermGen)) 移植到元空间(Metaspace)
格式为:t->y(u)]
JDK8 HotSpot JVM 使用本地内存来存储类元数据信息并称之为:元空间(Metaspace);这与Oracle JRockit 和IBM JVM’很相似。这将是一个好消息:意味着不会再有java.lang.OutOfMemoryError: PermGen问题默认情况下,类元数据只受可用的本地内存限制(容量取决于是32位或是64位操作系统的可用虚拟内存大小)
t 为元空间的垃圾回收前内存占用
y 为元空间的垃圾回收后内存占用
括号里的 u 为JVM元空间内存总大小
, 0.0068164 secs]
表示本次GC所消耗的时间。
[Times: user=0.00 sys=0.00, real=0.01 secs]
提供cpu使用及时间消耗
user :用是用户态消耗的cpu时间
sys :是系统态消耗的cpu时间
real :本次GC是实际的消耗时间
数据区块 | 堆总容量 | 使用容量 | 剩余容量 | 使用占比 |
---|---|---|---|---|
年轻代 | 8.0MB | 2.00MB | 5.99MB | 25.0% |
幸存者0 | 1.0MB | 0.00MB | 1.00MB | 0.0% |
幸存者1 | 1.0MB | 0.00MB | 1.00MB | 0.0% |
老年代 | 10.0MB | 6.54MB | 3.45MB | 65.4% |
年轻代 Eden Space 空间,使用量达到 25.0%,内存剩余5.99MB,当下次执行byte5(占用年轻代2M内存) 不会触发年轻代 Eden Space 空间 Minor GC(年轻代垃圾收集)。
老年代空间,使用量达到 6.54%,内存剩余3.45MB,当下次执行byte5(占用年轻代2M内存),不会触发老年代空间 Major GC(老年代垃圾收集),因为年轻代空间还够用。
执行完 byte5byte[] byte5 = new byte[2 * _1M];
$ jmap -heap 5636 ... Heap Usage: PS Young Generation Eden Space: capacity = 8388608 (8.0MB) used = 4356568 (4.154747009277344MB) free = 4032040 (3.8452529907226562MB) 51.9343376159668% used From Space: capacity = 1048576 (1.0MB) used = 0 (0.0MB) free = 1048576 (1.0MB) 0.0% used To Space: capacity = 1048576 (1.0MB) used = 0 (0.0MB) free = 1048576 (1.0MB) 0.0% used PS Old Generation capacity = 10485760 (10.0MB) used = 6861768 (6.543891906738281MB) free = 3623992 (3.4561080932617188MB) 65.43891906738281% used 1556 interned Strings occupying 143760 bytes.
数据区块 | 堆总容量 | 使用容量 | 剩余容量 | 使用占比 |
---|---|---|---|---|
年轻代 | 8.0MB | 4.15MB | 3.84MB | 51.9% |
幸存者0 | 1.0MB | 0.00MB | 1.00MB | 0.0% |
幸存者1 | 1.0MB | 0.00MB | 1.00MB | 0.0% |
老年代 | 10.0MB | 6.54MB | 3.45MB | 65.4% |
年轻代 Eden Space 空间,使用量达到 51.9%,内存剩余3.84MB,当下次执行byte6(占用年轻代5M内存),导致年轻代空间不够用了, 会触发年轻代 Eden Space 空间 Minor GC(年轻代垃圾收集),把一部分内存转移到 PS Old Generation 老年代。
老年代 PS Old Generation 空间,使用量达到 6.54%,内存剩余3.45MB,当下次执行byte6(占用年轻代5M内存),由于年轻代的一部分内存,转移到了老年代,导致老年代空间不够用了,会触发老年代 PS Old Generation 空间 Major GC(老年代垃圾收集)。
执行完 byte6byte[] byte6 = new byte[5 * _1M];控制台打印的GC日志
10342.704: [ Full GC (Ergonomics) [PSYoungGen: 4254K->2048K(9216K)] [ParOldGen: 6700K->8745K(10240K)] 10955K->10793K(19456K), [Metaspace: 2848K->2848K(1056768K)], 0.0154383 secs ] [Times: user=0.00 sys=0.03, real=0.02 secs]
这个GC 日志详细解读请参考,上面解读,执行完 byte4 的日志 ps(那个解读更详细)
这个是日志其实说的就是 :年轻代G回收前后,老年代GC回收前后,整个堆的GC回收前后,原数据空间回收前后,的内存使用情况。三个内存区块GC回收所消耗的时间,提供cpu使用及时间消耗时间
简单解读GC日志PS Young Generation 年轻代 Eden Space 空间,使用量达到 4254K,当执行byte6(占用年轻代5M内存),导致年轻代空间不够用了,会先触发年轻代 Eden Space 空间 Minor GC(年轻代垃圾收集),把一部分内存转移到 PS Old Generation 老年代,GC回收后 Eden Space 空间 剩余 2048K。
PS Old Generation 老年代空间,使用量达到 6700K,当执行byte6(占用年轻代5M内存),由于年轻代的一部分内存,转移到了老年代,导致老年代空间不够用了,会先触发老年代 PS Old Generation 空间 Major GC(老年代垃圾收集)。GC回收后 Eden Space 空间 剩余 8745K。
$ jmap -heap 5636 ... Heap Usage: PS Young Generation Eden Space: capacity = 8388608 (8.0MB) used = 7507856 (7.1600494384765625MB) free = 880752 (0.8399505615234375MB) 89.50061798095703% used From Space: capacity = 1048576 (1.0MB) used = 0 (0.0MB) free = 1048576 (1.0MB) 0.0% used To Space: capacity = 1048576 (1.0MB) used = 0 (0.0MB) free = 1048576 (1.0MB) 0.0% used PS Old Generation capacity = 10485760 (10.0MB) used = 8955872 (8.540985107421875MB) free = 1529888 (1.459014892578125MB) 85.40985107421875% used 1556 interned Strings occupying 143760 bytes.
数据区块 | 堆总容量 | 使用容量 | 剩余容量 | 使用占比 |
---|---|---|---|---|
年轻代 | 8.0MB | 7.16MB | 0.83MB | 89.5% |
幸存者0 | 1.0MB | 0.00MB | 1.00MB | 0.0% |
幸存者1 | 1.0MB | 0.00MB | 1.00MB | 0.0% |
老年代 | 10.0MB | 8.54MB | 1.45MB | 85.4% |
byte[] byte7 = new byte[2 * _1M];简单总结
参考 byte6 执行后,PS Young Generation 年轻代 Eden Space 空间,使用量达到 89.5%,内存剩余0.83MB,执行byte7(占用年轻代2M内存),导致年轻代空间不够用了,会触发Eden Space 空间(年轻代) Minor GC (年轻代垃圾收集)
参考 byte6 执行后,PS Old Generation 老年代空间,使用量达到 85.4%,内存剩余1.45MB,执行byte7(占用年轻代2M内存),会导致年轻代的GC回收放到老年代,而老年代也承担不了,会 OutOfMemoryError。
控制台打印的GC日志10427.298: [Full GC (Ergonomics) [PSYoungGen: 7331K->7168K(9216K)] [ParOldGen: 8745K->8745K(10240K)] 16077K->15913K(19456K), [Metaspace: 2849K->2849K(1056768K)], 0.0065366 secs] [Times: user=0.09 sys=0.02, real=0.01 secs] 10427.305: [Full GC (Allocation Failure) [PSYoungGen: 7168K->7168K(9216K)] [ParOldGen: 8745K->8745K(10240K)] 15913K->15913K(19456K), [Metaspace: 2849K->2849K(1056768K)], 0.0027873 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] Exception in thread "main" java.lang.OutOfMemoryError: Java heap space Heap at net.penglei.test.HeapTest.main(HeapTest.java:16) PSYoungGen total 9216K, used 7462K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000) eden space 8192K, 91% used [0x00000000ff600000,0x00000000ffd49b60,0x00000000ffe00000) from space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000) to space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000) ParOldGen total 10240K, used 8745K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000) object space 10240K, 85% used [0x00000000fec00000,0x00000000ff48a708,0x00000000ff600000) Metaspace used 2880K, capacity 4486K, committed 4864K, reserved 1056768K class space used 309K, capacity 386K, committed 512K, reserved 1048576K Disconnected from the target VM, address: "127.0.0.1:59679", transport: "socket" Process finished with exit code 1 。
[Full GC (Ergonomics) [PSYoungGen: 7331K->7168K(9216K)]
本次 Minor GC 发生在PS Young Generation 年轻代 Eden Space 空间,由于老年代已经占用85.4%,老年代空间不够用,本次年轻代垃圾回收没什么太大作用,只回收了一丢丢。
[ParOldGen: 8745K->8745K(10240K)]
本次 Major GC 发生在 PS Old Generation 老年代 ,由于老年代已经占用85.4% , 空间不够回收用,导致老年代回收没有效果**
16077K->15913K(19456K)
这些是告诉你,Exception 前 内存溢出前的堆占用情况
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space Heap at net.penglei.test.HeapTest.main(HeapTest.java:16) PSYoungGen total 9216K, used 7462K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000) eden space 8192K, 91% used [0x00000000ff600000,0x00000000ffd49b60,0x00000000ffe00000) from space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000) to space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000) ParOldGen total 10240K, used 8745K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000) object space 10240K, 85% used [0x00000000fec00000,0x00000000ff48a708,0x00000000ff600000) Metaspace used 2880K, capacity 4486K, committed 4864K, reserved 1056768K class space used 309K, capacity 386K, committed 512K, reserved 1048576K
此刻的 PS Young Generation 年轻代JVM 堆回收前占用16077K,年轻代JVM 堆回收后占用16077K ,JVM 堆总大小 19456K
[Full GC (Allocation Failure) [PSYoungGen: 7168K->7168K(9216K)] [ParOldGen: 8745K->8745K(10240K)] 15913K->15913K(19456K)
PSYoungGen 年轻代 Minor GC , ParOldGen 老年代 Major GC 老年代承担不了 15913K 内存,然后就 OutOfMemoryError 堆内存溢出了
为什了 老年代这次要 承担15913K 内存呢?因为前两次 Full GC 都没有成功,导致内存积压了一些在堆空间,堆空间自然放不下,然后要放到老年代,老年代放不下就堆内存溢出了
总结 内存分配与回收策略对象优先在新生代分配
大对象直接进入老年代
长期存活的对象将进入老年代
动态对象年龄判断:如果在Survivor空间中相同年龄所有对象大小总和大于Survivor空间的一半,大于或等于该年龄的对象直接进入老年代。
空间分配担保:发生Minor GC前,虚拟机会先检查老年代最大可用连续空间是否大于新生代所有对象总空间,如果不成立,虚拟机会查看HandlePromotionFailure设置值是否允许担保失败,如果允许继续检查老年代最大可用的连续空间是否大于历次晋升到老年代的平均大小,如果大于会尝试进行一次Minor GC;如果小于或者不允许冒险,会进行一次Full GC。
1 对象优先在eden分配大多数情况下,对象优先在新生代的Eden区分配。
当Eden区没有足够的空间时,虚拟机将发起一次Minor GC。
Minor GC与Full GC。
Minor GC:新生代GC,非常频繁,回收速度快。
Fulll GC:老年代GC,又称为Major GC,经常会伴随一次Minor GC,速度比较慢。
2 大对象直接进入老年代大对象是指需要大量连续的内存空间的Java对象,最典型的大对象就是那种很长的字符串以及数组。
虚拟机提供了一个参数:PretenureSizeThreshold,大于这个参数的对象将直接在老年代分配。
3 长期存活的对象将进入老年代虚拟机给每个对象定义了一个对象年龄计数器(Age),对象每经过一次Minor GC后仍然存活,且能被Survivor容纳的话,年龄就 +1 ,当年龄增加到一定程度(默认为15),就会被晋升到老年代中,这个阈值可以通过参数 MaxTenuringThreshold 来设置。
4.动态对象年龄的判定
4 动态对象年龄判定如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代。
5 空间分配担保为了更好的适应不同程序的内存状况,对象年龄不是必须到达阈值才会进入老年代。
只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC,否则将进行Full GC。
《深入理解Java虚拟机:JVM高级特性与最佳实践_周志明.高清扫描版.pdf》
下载地址:链接:http://pan.baidu.com/s/1miBQCBY 密码:9kbn
推荐阅读《深入理解Java虚拟机》(一)Java虚拟机发展史
《深入理解Java虚拟机》(二)Java虚拟机运行时数据区
《深入理解Java虚拟机》(三)垃圾收集器与内存分配策略
《深入理解Java虚拟机》(四)虚拟机性能监控与故障处理工具
《深入理解Java虚拟机》(五)JVM调优 - 工具
《深入理解Java虚拟机》(六)堆内存使用分析,GC 日志解读
Contact作者:鹏磊
出处:http://www.ymq.io
Email:admin@souyunku.com
版权归作者所有,转载请注明出处
Wechat:关注公众号,搜云库,专注于开发技术的研究与知识分享
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/67590.html
摘要:当两个对象相互引用时,这两个对象就不会被回收引用计数算法不被主流虚拟机采用,主要原因是它很难解决对象之间相互循环引用的问题。 垃圾收集器与内存分配策略 详解 3.1 概述 本文参考的是周志明的 《深入理解Java虚拟机》第三章 ,为了整理思路,简单记录一下,方便后期查阅。 3.2 对象已死吗 在垃圾收集器进行回收前,第一件事就是确定这些对象哪些还存活,哪些已经死去。 3.2.1 引用...
摘要:虚拟机性能监控与故障处理工具详解概述本文参考的是周志明的深入理解虚拟机第四章,为了整理思路,简单记录一下,方便后期查阅。虚拟机堆转储快照分析工具功能用于分析生成的。 虚拟机性能监控与故障处理工具 详解 4.1 概述 本文参考的是周志明的 《深入理解Java虚拟机》 第四章 ,为了整理思路,简单记录一下,方便后期查阅。 JDK本身提供了很多方便的JVM性能调优监控工具,除了集成式的Vis...
摘要:虚拟机发展史注本文大部分摘自深入理解虚拟机第二版作为一名开发人员,不能局限于语言规范,更需要对虚拟机规范有所了解。虚拟机规范有多种实现,其中是和中所带的虚拟机,也是目前使用范围最广的虚拟机。世界第一款商用虚拟机。号称世界上最快的虚拟机。 Java虚拟机发展史 注:本文大部分摘自《深入理解Java虚拟机(第二版)》 作为一名Java开发人员,不能局限于Java语言规范,更需要对Java虚...
摘要:看来还是功力不够,索性拆成了六篇文章,分别从自动内存管理机制类文件结构类加载机制字节码执行引擎程序编译与代码优化高效并发六个方面来做更加细致的介绍。本文先说说虚拟机的自动内存管理机制。在类加载检查通过后,虚拟机将为新生对象分配内存。 欢迎关注微信公众号:BaronTalk,获取更多精彩好文! 书籍真的是常读常新,古人说「书读百遍其义自见」还是蛮有道理的。周志明老师的这本《深入理解 Ja...
摘要:虚拟机运行时数据区分为以下几个部分。程序计数器也是在虚拟机规范中唯一没有规定任何异常情况的区域。在方法运行期间不会改变局部变量表的大小。长度在位和位的虚拟机中,分别为官方称它为。 Java虚拟机运行时数据区 详解 2.1 概述 本文参考的是周志明的 《深入理解Java虚拟机》第二章 ,为了整理思路,简单记录一下,方便后期查阅。 2.2 运行时数据区域 Java虚拟机在Java程序运行时...
阅读 899·2019-08-30 15:54
阅读 1467·2019-08-30 15:54
阅读 2403·2019-08-29 16:25
阅读 1294·2019-08-29 15:24
阅读 750·2019-08-29 12:11
阅读 2507·2019-08-26 10:43
阅读 1229·2019-08-26 10:40
阅读 468·2019-08-23 16:24