gc

package com.shi.gc; /** * 查看默认GC: -XX:+PrintCommandLineFlags -version * 结果： -XX:InitialHeapSize=127115712 -XX:MaxHeapSize=2033851392 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC java version "1.8.0_121" Java(TM) SE Runtime Environment (build 1.8.0_121-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) * @author shiye * */ public class TestGC { public static void main(String[] args) { } } 来源： https://my.oschina.net/u/3677987/blog/3111407

一、背景 线上一个项目，每次机器重启时项目都会报出大量的Timeout，同时每个集群节点都被监控到较为频繁的Full GC。之后同事虽然尝试过JVM调优并适当调大了老年代空间，但依然不能根本上解决问题。当时该问题被初步归咎于系统中整合的Groovy，但并未证实。问题汇总如下： 问题一：项目启动时报出大量Timeout； 问题二：项目运行时，频繁Full GC； 随后，我着手做另外一个项目GLUE，该项目同样需要整合Groovy，在做并发测试时，我发现了同样的问题。 经过排查并做出优化，新项目GLUE在并发测试下基本不存在Full GC的问题，在此将问题处理过程记录如下，希望可以给大家一点参考。 二、分析 新系统GLUE底层基于Groovy实现，系统通过执行 “groovy.lang.GroovyClassLoader.parseClass(groovyScript)” 进行Groovy代码解析，Groovy为了保证解析后执行的都是最新的脚本内容，每进行一次解析都会生成一次新命名的Class文件，底层代码如下图： 因此，如果Groovy类加载器设置为单例，当对脚本（即使同一段脚本）多次执行该方法时，会导致 “GroovyClassLoader” 装载的Class越来越多。如果此处临时加载的类不能够被及时释放，最终将会导致PermGen OutOfMemoryError

在一些规模稍大的应用中，Java虚拟机（JVM）的内存设置尤为重要，想在项目中取得好的效率，GC（垃圾回收）的设置是第一步。 PermGen space：全称是Permanent Generation space.就是说是永久保存的区域,用于存放Class和Meta信息,Class在被Load的时候被放入该区域Heap space：存放Instance。 GC(Garbage Collection)应该不会对PermGen space进行清理,所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误 Java Heap分为3个区 1.Young 2.Old 3.Permanent Young区保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象，本文不讨论该区。 JVM的Heap分配可以使用-X参数设定， -Xms 初始Heap大小 -Xmx java heap最大值 -Xmn young generation的heap大小 JVM有2个GC线程 第一个线程负责回收Heap的Young区 第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区 Old区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。 为什么一些程序频繁发生GC

本文是成为Java GC专家系列文章的第三篇。在第一篇《 成为JavaGC专家Part I — 深入浅出Java垃圾回收机制 》中我们学习了不同GC算法的执行过程，GC是如何工作的，什么是新生代和老年代，你应该了解的JDK7中的5种GC类型，以及这5种类型对于应用性能的影响。 在第二篇《 成为JavaGC专家Part II — 如何监控Java垃圾回收机制 》， 我解释了JVM实际上是如何执行垃圾回收的，我们如何监控GC，以及那哪些具可以让我们的工作更快，更高效。在第三篇文章中，我们会基于实际的例子来解释 一些优化GC的最佳实践。我认为在阅读本篇文章之前，你已经很好地理解了之前的文章，因此，为了你能够更好地学习本文，如果你还没有读过之前的两篇文章 话，请先阅读。 为什么需要优化 GC 或者说的更确切一些， 对于基于 Java 的服务，是否有必要优化 GC ？ 应该说，对于所有的基于Java的服务，并不总是需要进行GC优化，但前提是所运行的基于Java的系统，包含了如下参数或行为： 已经通过 -Xms 和–Xmx 设置了内存大小 包含了 -server 参数 系统中没有超时日志等错误日志 换句话说，如果你没有设定内存的大小，并且系统充斥着大量的超时日志时，你就需要在你的系统中进行 GC 优化了。 但是，你需要时刻铭记一条 ： GC 优化永远是最后一项任务。

这是“成为Java GC专家系列文章”的第四篇。 在第一篇文章 成为JavaGC专家Part I — 深入浅出Java垃圾回收机制 中我们学习了不同GC算法的执行过程，GC如何工作，新生代及老年代的基本概念，在JDK7中你应该了解的5种GC类型以及他们的性能如何。 在第二篇文章 成为JavaGC专家Part II — 如何监控Java垃圾回收机制 中我们学到了JVM到底是如何执行垃圾回收，我们如何监控GC，以及那些工具可以使得监控过程更高效。 在第三篇文章 成为Java GC专家系列Part III–如何优化Java垃圾回收机制 中我们通过实际的例子学到了一些可以优化GC的参数。同时我们讲解了如何减少对象被转移到老年代空间，如何缩短Full GC时间，以及如何设置GC类型及内存空间。 在第四篇文章中，我们将阐述Apache中 MaxClients 参数的重要性，以及他如何在GC发生时，显著地影响整个系统的性能。我将提供几个例子以方便你理解 MaxClients 导致的问题。同时我还会说明如何根据系统的内存情况，设置最佳的 MaxClients 参数值。 MaxClients对于系统的影响 NHN (译者注：NHN是作者工作的公司)服务的执行环境中存在一组 Throttle valve -type参数（译者注：节流阀参数，用于控制系统负载）。这些参数对于系统来说十分重要

很多开发者都在其系统中见过“java.lang.OutOfMemoryError: PermGen space”这一问题。这往往是由类加载器相关的内存泄漏以及新类加载器的创建导致的，通常出现于代码热部署时。相对于正式产品，该问题在开发机上出现的频率更高，在产品中最常见的“问题”是默认值太低了。常用的解决方法是将其设置为256MB或更高。 PermGen space简单介绍 PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，说说为什么会内存益出：这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。这种错误常见在web服务器对JSP进行pre compile的时候。 JVM 种类有很多，比如 Oralce-Sun Hotspot, Oralce JRockit, IBM J9, Taobao JVM（淘宝好样的！）等等。当然武林盟主是Hotspot了，这个毫无争议。 需要注意的是，PermGen space是Oracle-Sun Hotspot才有 ，JRockit以及J9是没有这个区域。 元空间（MetaSpace

Java的内存分配与回收全部由JVM垃圾回收进程自动完成。与C语言不同，Java开发者不需要自己编写代码实现垃圾回收。这是Java深受大家欢迎的众多特性之一，能够帮助程序员更好地编写Java程序。 下面 四篇教程 是了解Java 垃圾回收（GC）的基础： 垃圾回收简介 圾回收是如何工作的？ 垃圾回收的类别 垃圾回收监视和分析 这篇教程是系列第一部分。首先会解释基本的术语，比如JDK、JVM、JRE和HotSpotVM。接着会介绍JVM结构和Java 堆内存结构。理解这些基础对于理解后面的垃圾回收知识很重要。 Java GC系列（1）：Java垃圾回收简介 Java关键术语 JavaAPI：一系列帮助开发者创建Java应用程序的封装好的库。 Java 开发工具包 （JDK）：一系列工具帮助开发者创建Java应用程序。JDK包含工具编译、运行、打包、分发和监视Java应用程序。 Java 虚拟机（JVM）：JVM是一个抽象的计算机结构。Java程序根据JVM的特性编写。JVM针对特定于操作系统并且可以将Java指令翻译成底层系统的指令并执行。JVM确保了Java的平台无关性。 Java 运行环境（JRE）：JRE包含JVM实现和Java API。 Java HotSpot 虚拟机 每种JVM实现可能采用不同的方法实现垃圾回收机制。在收购SUN之前，Oracle使用的是JRockit

如果您还在用Java 6的话，请赶紧升级到Java 7吧。 以下以Java 7为基准来讨论。 ============================================================== 在Java 7里有两种办法来监听GC事件。 一种是比较传统的办法，从Java SE 5开始就可用。 用C或C++或其它native语言来实现一个JVMTI agent，注册监听里面的 GarbageCollectionFinish 事件即可。 JVMTI提供了GarbageCollectionStart和GarbageCollectionFinish事件，有需要的话前者也可以监听上。这两个事件都是在JVM处于GC暂停阶段之中发出的，此时不能执行任何Java代码。 可以通过JVMTI的 GetStackTrace 函数来获取当时某个指定的Java线程的栈，或者用 GetAllStackTraces 来获取所有Java线程的栈。 -------------------------------------------------------------- 另一种是用Java 7新推出的JMX API的GC notification。用Java代码注册一个NotificationListener来监听GC事件即可。这边的事件是在GC完成之后才发出的。可以配置超时时间

这是“ 成为Java GC专家 ”系列的第五篇文章。在第一篇 深入浅出Java垃圾回收机制 中，我们已经学习了不同的GC算法流程、GC的工作原理、新生代（Young Generation）和老年代（Old Generation）的概念。你应该了解了JDK7中5种GC类型以及各种类型对应用程序的影响。 在第二篇 如何监控Java的垃圾回收 中，阐述了 JVM 是怎样实际执行垃圾回收的，我们怎样去监控GC以及哪些工具能让这个过程更高效。 第三篇 如何如何优化Java垃圾回收机制 中展示了一些基于真实案例的最佳实践。同时讲解了怎样尽量少地将对象放入老年代空间（Old Area），避免频繁地执行完全垃圾回收（Full GC）。还说明了如何设置GC的类型和内存大小。 在第四篇 Apache的MaxClients参数详解及其在Tomcat执行FullGC时的影响 中，解释了MaxClients参数的重要性以及它在垃圾回收过程中对整个系统性能的显著影响。 第五篇文章将讲解Java程序性能调优的原则，尤其是在这个过程中必要的知识以及判断你的程序是否需要调优。还会介绍调优过程中你可能遇到的问题。本文最后会给出一些建议，依据这些你能在对Java程序调优时做出更好的决策。 概述 并不是每个程序都需要调优。如果一个程序性能表现和预期一样，你不必付出额外的精力去提高它的性能。然而，在程序调试完成之后

从年轻代空间（包括Eden和Survivor区域）回收内存被称为Minor GC，对老年代GC成为Major GC ,而Full GC是对整个堆来说的，出现Full GC的时候经常伴随至少一次的Minor GC，但非绝对的。Major GC的速度一般会比Minor GC慢10倍以上 来源： https://my.oschina.net/u/4177395/blog/3086421