转载自：《JVM的新生代、老年代、MinorGC、MajorGC》
JVM中的堆，一般分为三大部分：新生代、老年代、永久代：
1 新生代
主要是用来存放新生的对象。一般占据堆的1/3空间。由于频繁创建对象，所以新生代会频繁触发MinorGC进行垃圾回收。
新生代又分为 Eden区、ServivorFrom、ServivorTo三个区。
jmap是java 7后自带的轻量级内存分析工具，原文介绍可以见官网，《The jmap Utility》
1 堆栈分析
获取GC算法，新生代，老年代，永久代空间占用分析
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
jmap -heap 29620 Attaching to process ID 29620, please wait... Debugger attached successfully. Client compiler detected. JVM version is 1.6.0-rc-b100 using thread-local object allocation. Mark Sweep Compact GC Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 67108864 (64.0MB) NewSize = 2228224 (2.125MB) MaxNewSize = 4294901760 (4095.9375MB) OldSize = 4194304 (4.0MB) NewRatio = 8 SurvivorRatio = 8 PermSize = 12582912 (12.0MB) MaxPermSize = 67108864 (64.0MB) Heap Usage: New Generation (Eden + 1 Survivor Space): capacity = 2031616 (1.9375MB) used = 70984 (0.06769561767578125MB) free = 1960632 (1.8698043823242188MB) 3.4939673639112905% used Eden Space: capacity = 1835008 (1.75MB) used = 36152 (0.03447723388671875MB) free = 1798856 (1.7155227661132812MB) 1.9701276506696428% used From Space: capacity = 196608 (0.1875MB) used = 34832 (0.0332183837890625MB) free = 161776 (0.1542816162109375MB) 17.716471354166668% used To Space: capacity = 196608 (0.1875MB) used = 0 (0.0MB) free = 196608 (0.1875MB) 0.0% used tenured generation: capacity = 15966208 (15.2265625MB) used = 9577760 (9.134063720703125MB) free = 6388448 (6.092498779296875MB) 59.98769400974859% used Perm Generation: capacity = 12582912 (12.0MB) used = 1469408 (1.401336669921875MB) free = 11113504 (10.598663330078125MB) 11.677805582682291% used |
2 堆详细对象分析
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
jmap -histo 29620 num #instances #bytes class name -------------------------------------- 1: 1414 6013016 [I 2: 793 482888 [B 3: 2502 334928 <constMethodKlass> 4: 280 274976 <instanceKlassKlass> 5: 324 227152 [D 6: 2502 200896 <methodKlass> 7: 2094 187496 [C 8: 280 172248 <constantPoolKlass> 9: 3767 139000 [Ljava.lang.Object; 10: 260 122416 <constantPoolCacheKlass> 11: 3304 112864 <symbolKlass> 12: 160 72960 java2d.Tools$3 13: 192 61440 <objArrayKlassKlass> 14: 219 55640 [F 15: 2114 50736 java.lang.String 16: 2079 49896 java.util.HashMap$Entry 17: 528 48344 [S 18: 1940 46560 java.util.Hashtable$Entry 19: 481 46176 java.lang.Class 20: 92 43424 javax.swing.plaf.metal.MetalScrollButton ... more lines removed here to reduce output... 1118: 1 8 java.util.Hashtable$EmptyIterator 1119: 1 8 sun.java2d.pipe.SolidTextRenderer Total 61297 10152040 |
3 永久代分析
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
jmap -permstat 29620 Attaching to process ID 29620, please wait... Debugger attached successfully. Client compiler detected. JVM version is 1.6.0-rc-b100 12674 intern Strings occupying 1082616 bytes. finding class loader instances ..Unknown oop at 0xd0400900 Oop's klass is 0xd0bf8408 Unknown oop at 0xd0401100 Oop's klass is null done. computing per loader stat ..done. please wait.. computing liveness.........................................done. class_loader classes bytes parent_loader alive? type <bootstrap> 1846 5321080 null live <internal> 0xd0bf3828 0 0 null live sun/misc/Launcher$ExtClassLoader@0xd8c98c78 0xd0d2f370 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0c99280 1 1440 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0b71d90 0 0 0xd0b5b9c0 live java/util/ResourceBundle$RBClassLoader@0xd8d042e8 0xd0d2f4c0 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0b5bf98 1 920 0xd0b5bf38 dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0c99248 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0d2f488 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0b5bf38 6 11832 0xd0b5b9c0 dead sun/reflect/misc/MethodUtil@0xd8e8e560 0xd0d2f338 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0d2f418 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0d2f3a8 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0b5b9c0 317 1397448 0xd0bf3828 live sun/misc/Launcher$AppClassLoader@0xd8cb83d8 0xd0d2f300 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0d2f3e0 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0ec3968 1 1440 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0e0a248 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0c99210 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0d2f450 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0d2f4f8 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 0xd0e0a280 1 904 null dead sun/reflect/DelegatingClassLoader@0xd8c22f50 total = 22 2186 6746816 N/A alive=4, dead=18 N/A |
在IDC跨机房，或者docker集群的使用中，经常会有这样的需求：
本地办公网络可以直接访问远程IDC集群的内网。
有两种方案：
路由表是最稳妥的做法，但是双向设置比较繁琐，而且容易出错。
本文介绍的是iptables + openvpn方案。
１、方案：
本地LAN <– iptables+NAT –> 带openvpn的中转软路由 <– openvpn –> 远程i[……]
一个简单的实验，具体见 Internet/ConnectionSharing
说一下实验环境，两台vm虚拟机，Ubuntu 16.04
也就是说，我们想让tmp2通过tmp1连接互联网。
这里的做法是让tmp1的网卡2和tmp2的网卡1在同一个网段，然后在tmp1上通过iptables完[……]