JVM内存模型和垃圾收集

《JVM内存模型和垃圾收集》由会员分享，可在线阅读，更多相关《JVM内存模型和垃圾收集（35页珍藏版）》请在金锄头文库上搜索。

1、JVM内存模型和垃圾收集fanzhang 2009.08.31意义何在n内存和垃圾收集对Java程序的性能起着 至关重要的作用，特别是对服务器程序 。n遭遇OOM？响应速度慢？并发上不去？ 吞吐量不够？n内存和垃圾收集是Java程序的OS。遍布问号的底层n堆？：根集合？、链结构、老的居底、 从顶分配、可达性、活跃对象n栈在哪里？：主内存和工作内存？栈空 间也要配置？n引用：强引用和弱引用？垃圾收集不用 引用计数用什么（无法回收：树、子指 向父）？引用值会被改变？对象哈希值 何时与之相关？堆（Heap）nJVM管理的内存叫堆（Heap）；32位 Linux最大3G；64位无限制n初始-Xms：默

2、认1/64但小于1G。 最大-Xmx：默认1/4但小于1G。 -Xms与-Xms设置相同值，对服务端应用 来说要给足空间（重要）n最小空余-XX:MinHeapFreeRatio=40%。 最大空余-XX:MaxHeapFreeRatio=70% 。堆的分代（Generation）n堆分为三个代：Young、Old和 Permanent，不同代采用不同的垃圾收集 算法，以提升性能。（注：Permanent空 间在大小上并没有计算在Heap空间之内 ）如下图： 年轻代（Young）n年轻代采取复制收集算法。分为3个区域：一 个Eden，所有新建对象；两个Survivor区，用 来实施复制算法。n

3、-XX:NewRatio=Young:Old，推荐1:3 -XX:NewSize和-XX:MaxNewSize设置相同值， 适当放大，减少GC（重要）n-XX:SurvivorRatio= Eden:1个Survivor，默认 比例8，适当减小，防止老年化（重要）老年代（Old）n年轻代的对象挺过数次收集，就会进入 老年代。老年代使用标记整理算法。老 年代存活时间长，不用复制算法。n-XX:MaxTenuringThreshold=年轻代熬过 多少次收集后进入老年代。持久代（Permanent）n装载Class信息等基础数据nXX:MaxPermSize=64M，满了之后会引 起一种不同类型的

4、 OOM。类很多很多的 程序，需要加大之，一般使用默认值即 可。GC的类型nMinor Collection：对Young，复制算法， 频率高。nMajor Collection：同时对Young和Old， 也叫Full GC；Old频率要比Young低很多 ，采用标记清除/标记整理算法； System.gc()可以建议引发之，使用- XX:+DisableExplicitGC禁止代码调用。nYoung的GC频繁，范围小，速度快，称之为 Minor Collection。nEden+1Suvivor空间达阀值 - 移动对象到to space - to space与from space互换角色

5、- 对象移动次 数到阀值就足够老了-Old。nSurvivor是Eden和Old的缓冲区，为Old把关，减少 Old的大小和GC频次，Suvivor不足会Old化。nOld的GC范围广，较慢，频率低称之为Major Collection(Full Collection)。n先Young GC，再Old GC。垃圾收集算法n复制(copying)：将堆内分成两个相同空间，从 根开始访问每一个关联的活跃对象。 将空间A的活跃对象全部复制到空间B，然后一 次性回收整个空间A。 只访问活跃对象，遍历空间的成本较小，但需 要巨大的复制成本和较多的内存，需要修改引 用值。 如下图： n标记清除(mark-

6、sweep)：收集器先从根开始访 问所有活跃对象，标记为活跃对象。 然后再遍历一次整个内存区域，把所有没有标 记活跃的对象进行回收处理。 遍历整个空间的成本较大、暂停时间随空间大 小线性增大、整理后堆里的碎片很多。 如下图： n标记整理(mark-sweep-compact)：综合 了上述两者的做法和优点，先标记活跃 对象，然后将其合并成较大的内存块。 如下图： GC收集器类型n串行收集器(Serial Collector) -XX:+UseSerialGC：年轻代串行复制， 老年代串行标记整理。（注：目前已不 使用）如下图： n并行收集器(Throughput Collector) -XX:

7、+UseParallelGC：JDK5.0以上-server（ Linux的JDK默认是-server）的默认值。年轻代：暂停应用程序，多个垃圾收集线程并 行的复制收集，线程数默认为CPU个数，可用- XX:ParallelGCThreads= 设定线程数。 年老代：暂停应用程序，与串行收集器一样， 单垃圾收集线程标记整理。 从上可知该收集器需要2+的CPU时才会优于串 行收集器。 如下图： n并发收集器(Concurrent Low Pause Collector-CMS) -XX:+UseConcMarkSweepGC：这是以上两种策略的升 级版。 年轻代：同样是暂停应用程序，多个垃圾收集

8、线程并 行的复制收集。 年老代：则只有两次短暂停，其他时间应用程序与收 集线程并发的清除。 对响应时间要求高的服务器应用，应手工配置使用这 种收集器。（重要） -XX:CMSInitiatingOccupancyFraction=68%配合使用 ，可以适当增大此值。 如下图： n增量并发收集器(Incremental Concurrent-Mark-Sweep/i-CMS)：在CPU 资源不足下使用CMS。n即将问世的Garbage First Collection（G1 ）：JDK7.0，新的算法与巨大的性能提 升。（世界属于搞C+的，也属于搞 Java的，但最终还是属于搞C的）查看堆nmq

9、q16_186:/resin-wapqq2008 jmap -heap 28146nAttaching to process ID 28146, please wait.nDebugger attached successfully.nServer compiler detected.nJVM version is 11.2-b01nusing parallel threads in the new generation.nusing thread-local object allocation.nConcurrent Mark-Sweep GCnHeap Configuration:n Mi

10、nHeapFreeRatio = 40n MaxHeapFreeRatio = 70n MaxHeapSize = 1048576000 (1000.0MB)n NewSize = 262144000 (250.0MB)n MaxNewSize = 262144000 (250.0MB)n OldSize = 786432000 (750.0MB)n NewRatio = 7n SurvivorRatio = 8n PermSize = 21757952 (20.75MB)n MaxPermSize = 88080384 (84.0MB)nHeap Usage:nNew Generation

11、(Eden + 1 Survivor Space):n capacity = 235929600 (225.0MB)n used = 38844960 (37.045440673828125MB)n free = 197084640 (187.95455932617188MB)n 16.464640299479168% usednEden Space:n capacity = 209715200 (200.0MB)n used = 37723976 (35.97638702392578MB)n free = 171991224 (164.02361297607422MB)n 17.988193

12、51196289% usednFrom Space:n capacity = 26214400 (25.0MB)n used = 1120984 (1.0690536499023438MB)n free = 25093416 (23.930946350097656MB)n 4.276214599609375% usednTo Space:n capacity = 26214400 (25.0MB)n used = 0 (0.0MB)n free = 26214400 (25.0MB)n 0.0% usednconcurrent mark-sweep generation:n capacity

13、= 786432000 (750.0MB)n used = 43648992 (41.626922607421875MB)n free = 742783008 (708.3730773925781MB)n 5.55025634765625% usednPerm Generation:n capacity = 21757952 (20.75MB)n used = 8137176 (7.760215759277344MB)n free = 13620776 (12.989784240722656MB)n 37.39863016519202% used查看线程n状态n调用堆栈n辅助阅读代码n垃圾收集

14、线程n观察线程池大小nqq16_186:/resin-wapqq2008 jstack 28146 | moren2009-09-01 11:31:50nFull thread dump Java HotSpot(TM) 64-Bit Server VM (11.2-b01 mixed mode):n“Attach Listener“ daemon prio=10 tid=0x00002aaaf5b08400 nid=0x49db runnable 0x0000000000000000.0x0000000000000000n java.lang.Thread.State: RUNNABLEn“

15、NioProcessor-3“ prio=10 tid=0x00002aaaf44bb800 nid=0x7a86 runnable 0x0000000042b53000.0x0000000042b53ca0n java.lang.Thread.State: RUNNABLEn at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)n at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:215)n at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)n at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)n - locked (a sun.nio.ch.Util$1)n - locked (a java.util.Collections$UnmodifiableSet)n - locked (a sun.nio.ch.EPollSelectorImpl)n at sun.nio.c