java jvm 参数 -Xms -Xmx -Xmn -Xss 调优总结

JVM调优总结(三)基本垃圾回收算法

可以从不同的的角度去划分垃圾回收算法： 按照基本回收策略分 引用计数（Reference Counting）: 比较古老的回收算法。原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只用收集计数为0的对象。此算法最致命的是无法处理循环引用的问题。 标记-清除（Mark-Sweep）: 此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，同时，会产生内存碎片。 复制（Copying）:

此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。次算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不会出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。 标记-整理（Mark-Compact）:

此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。 按分区对待的方式分 增量收集（Incremental Collecting）:实时垃圾回收算法，即：在应用进行的同时进行垃圾回收。不知道什么原因JDK5.0中的收集器没有使用这种算法的。 分代收集（Generational Collecting）:基于对对象生命周期分析后得出的垃圾回收算法。把对象分为年青代、年老代、持久代，对不同生命周期的对象使用不同的算法（上述方式中的一个）进行回收。现在的垃圾回收器（从J2SE1.2开始）都是使用此算法的。 按系统线程分 串行收集:串行收集使用单线程处理所有垃圾回收工作，因为无需多线程交互，实现容易，而且效率比较高。但是，其局限性也比较明显，即无法使用多处理器的优势，所以此收集适合单处理器机器。当然，此收集器也可以用在小数据量（100M左右）情况下的多处理器机器上。 并行收集:并行收集使用多线程处理垃圾回收工作，因而速度快，效率高。而且理论上CPU数目越多，越能体现出并行收集器的优势。 并发收集:相对于串行收集和并行收集而言，前面两个在进行垃圾回收工作时，需要暂停整个运行环境，而只有垃圾回收程序在运行，因此，系统在垃圾回收时会有明显的暂停，而且暂停时间会因为堆越大而越长。

JVM的垃圾回收机制小读

JVM的垃圾回收机制小读 技术2010-05-09 19:41:04 阅读20 评论2 字号：大中小订阅 今天下午突然遇到了一个内存漏洞的问题，所以上网查了查，结果看到了一篇文章，说的是jvm的垃圾回收机制，下面粘过来，看了好久才看完的，说的思路有点含糊，还给带了点代码，这样还不错……对JVM 的内存管理机制有加深了一层理解哈………… 下面是那篇文章，喜欢的可以看看…………O(∩_∩)O………… Java的堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，这些对象通过new、newarray、anewarray和multianewarray等指令建立， 但是它们不需要程序代码来显式地释放。 引言 Java的堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，这些对象通过new、newarray、anewarray和multianewarray等指令建立，但是它们不需要程序代码来显式地释放。一般来说，堆的是由垃圾回收来负责的，尽管JVM规范并不要求特殊的垃圾回收技术，甚至根本就不需要垃圾回收，但是由于内存的有限性，JVM在实现的时候都有一个由垃圾回收所管理的堆。垃圾回收是一种动态存储管理技术，它自动地释放不再被程序引用的对象，按照特定的垃圾收集算法来实现资源自动回收的功能。 垃圾收集的意义 在C++中，对象所占的内存在程序结束运行之前一直被占用，在明确释放之前不能分配给其它对象；而在Java中，当没有对象引用指向原先分配给某个对象的内存时，该内存便成为垃圾。JVM的一个系统级线程会自动释放该内存块。垃圾收集意味着程序不再需要的对象是"无用信息"，这些信息将被丢弃。当一个对象不再被引用的时候，内存回收它占领的空间，以便空间被后来的新对象使用。事实上，除了释放没用的对象，垃圾收集也可以清除内存记录碎片。由于创建对象和垃圾收集器释放丢弃对象所占的内存空间，内存会出现碎片。碎片是分配给对象的内存块之间的空闲内存洞。碎片整理将所占用的堆内存移到堆 的一端，JVM将整理出的内存分配给新的对象。 垃圾收集能自动释放内存空间，减轻编程的负担。这使Java 虚拟机具有一些优点。首先，它能使编程效率提高。在没有垃圾收集机制的时候，可能要花许多时间来解决一个难懂的存储器问题。在用Java 语言编程的时候，靠垃圾收集机制可大大缩短时间。其次是它保护程序的完整性，垃圾收集是Java语言 安全性策略的一个重要部份。 垃圾收集的一个潜在的缺点是它的开销影响程序性能。Java虚拟机必须追踪运行程序中有用的对象，而且最终释放没用的对象。这一个过程需要花费处理器的时间。其次垃圾收集算法的不完备性，早先采用的某些垃圾收集算法就不能保证100%收集到所有的废弃内存。当然随着垃圾收集算法的不断改进以及软硬件运行效率的不断提升，这些问题都可以迎刃而解。 垃圾收集的算法分析

JVM内存分配(栈堆)与JVM回收机制

Java 中的堆和栈 简单的说： Java把内存划分成两种：一种是栈内存，一种是堆内存。 在函数中定义的一些基本类型的变量和对象的引用变量都在函数的栈内存中分配。 当在一段代码块定义一个变量时，Java就在栈中为这个变量分配内存空间，当超过变量的作用域后，Java会自动释放掉为该变量所分配的内存空间，该内存空间可以立即被另作他用。 堆内存用来存放由new创建的对象和数组。 在堆中分配的内存，由Java虚拟机的自动垃圾回收器来管理。 在堆中产生了一个数组或对象后，还可以在栈中定义一个特殊的变量，让栈中这个变量的取值等于数组或对象在堆内存中的首地址，栈中的这个变量就成了数组或对象的引用变量。 引用变量就相当于是为数组或对象起的一个名称，以后就可以在程序中使用栈中的引用变量来访问堆中的数组或对象。 具体的说： 栈与堆都是Java用来在Ram中存放数据的地方。与C++不同，Java自动管理栈和堆，程序员不能直接地设置栈或堆。 Java的堆是一个运行时数据区,类的(对象从中分配空间。这些对象通过new、newarray、anewarray和multianewarray等指令建立，它们不需要程序代码来显式的释放。堆是由垃圾回收来负责的，堆的优势是可以动态地分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的，Java的垃圾收集器会自动收走这些不再使用的数据。但缺点是，由于要在运行时动态分配内存，存取速度较慢。 栈的优势是，存取速度比堆要快，仅次于寄存器，栈数据可以共享。但缺点是，存在栈中的数据大小与生存期必须是确定的，缺乏灵活性。栈中主要存放一些基本类型的变量（,int, short, long, byte, float, double, boolean, char）和对象句柄。 栈有一个很重要的特殊性，就是存在栈中的数据可以共享。假设我们同时定义： int a = 3; int b = 3； 编译器先处理int a = 3；首先它会在栈中创建一个变量为a的引用，然后查找栈中是否有3这个值，如果没找到，就将3存放进来，然后将a指向3。接着处理int b = 3；在创建完b的引用变量后，因为在栈中已经有3这个值，便将b直接指向3。这样，就出现了a与b同时均指向3的情况。这时，如果再令a=4；那么编译器会重新搜索栈中是否有4值，如果没有，则将4存放进来，并令a指向4；如果已经有了，则直接将a指向这个地址。因此a值的改变不会影响到b 的值。要注意这种数据的共享与两个对象的引用同时指向一个对象的这种共享是不同的，因为这种情况a的修改并不会影响到b, 它是由编译器完成的，它有利于节省空间。而一个对象引用变量修改了这个对象的内部状态，会影响到另一个对象引用变量。 String是一个特殊的包装类数据。可以用： String str = new String("abc"); String str = "abc"; 两种的形式来创建，第一种是用new()来新建对象的，它会在存放于堆中。每调用一次就会创建一个新的对象。 而第二种是先在栈中创建一个对String类的对象引用变量str，然后查找栈中有没有存放"abc"，如果没有，则将"abc"存放进栈，并令str指向”abc”，如果已经有”abc”则直接令 str指向“abc”。 比较类里面的数值是否相等时，用equals()方法；当测试两个包装类的引用是否指向同一个对象时，用==，下面用例子说明上面的理论。 String str1 = "abc"; String str2 = "abc"; System.out.println(str1==str2); //true

JVM调优总结

JVM调优总结 作者: 和你在一起https://www.wendangku.net/doc/1a3023836.html, 程序员其实很痛苦的，每隔一段时间就会听到、看到很多很多新名词、新技术---囧.幸而有了互联网，有了开源、有了wiki、有了分享：）—人人为我，我为人人。拓荒者走过的时候很痛苦，但是如果能给后来人留下点路标，是不是可以让他们少走一些弯路呢？踏着前辈的足迹我走到了这里，也应该为后来的人留下点东西。走夜路其实不可怕，可怕的是一个人走夜路：）https://www.wendangku.net/doc/1a3023836.html, - 做最棒的软件开发交流社区 A-PDF Number Pro DEMO: Purchase from https://www.wendangku.net/doc/1a3023836.html, to remove the watermark

目 录 1. java路上 1.1 JVM调优总结-序 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 1.2 JVM调优总结（一）-- 一些概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 1.3 JVM调优总结（二）-一些概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 1.4 JVM调优总结（三）-基本垃圾回收算法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 1.5 JVM调优总结（四）-垃圾回收面临的问题 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 1.6 JVM调优总结（五）-分代垃圾回收详述1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 1.7 JVM调优总结（六）-分代垃圾回收详述2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 1.8 JVM调优总结（七）-典型配置举例1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 1.9 JVM调优总结（八）-典型配置举例2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 1.10 JVM调优总结（九）-新一代的垃圾回收算法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 1.11 JVM调优总结（十）-调优方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 1.12 JVM调优总结（十一）-反思 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 1.13 JVM调优总结（十二）-参考资料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

JVM内存管理：深入垃圾收集器与内存分配策略

JVM内存管理：深入垃圾收集器与内存分配策略 https://www.wendangku.net/doc/1a3023836.html, 时间：2010-11-20 作者：网络编辑：fnw 点击： 6 [ 评论] - - Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的高墙，墙外面的人想进去，墙里面的人却想出来。 概述： 说起垃圾收集（Garbage Collection，下文简称GC），大部分人都把这项技术当做Java 语言的伴生产物。事实上GC的历史远远比Java来得久远，在1960年诞生于MIT的Lisp 是第一门真正使用内存动态分配和垃圾收集技术的语言。当Lisp还在胚胎时期，人们就在思考GC需要完成的3件事情：哪些内存需要回收？什么时候回收？怎么样回收？ 经过半个世纪的发展，目前的内存分配策略与垃圾回收技术已经相当成熟，一切看起来都进入“自动化”的时代，那为什么我们还要去了解GC和内存分配？答案很简单：当需要排查各种内存溢出、泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术有必要的监控、调节手段。 把时间从1960年拨回现在，回到我们熟悉的Java语言。本文第一章中介绍了Java内存运行时区域的各个部分，其中程序计数器、VM栈、本地方法栈三个区域随线程而生，随线程而灭；栈中的帧随着方法进入、退出而有条不紊的进行着出栈入栈操作；每一个帧中分配多少内存基本上是在Class文件生成时就已知的（可能会由JIT动态晚期编译进行一些优化，但大体上可以认为是编译期可知的），因此这几个区域的内存分配和回收具备很高的确定性，因此在这几个区域不需要过多考虑回收的问题。而Java堆和方法区（包括运行时常量池）则不一样，我们必须等到程序实际运行期间才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，我们本文后续讨论中的“内存”分配与回收仅仅指这一部分内存。 对象已死？ 在堆里面存放着Java世界中几乎所有的对象，在回收前首先要确定这些对象之中哪些还在存活，哪些已经“死去”了，即不可能再被任何途径使用的对象。 引用计数算法（Reference Counting） 最初的想法，也是很多教科书判断对象是否存活的算法是这样的：给对象中添加一个引用计数器，当有一个地方引用它，计数器加1，当引用失效，计数器减1，任何时刻计数器为0的对象就是不可能再被使用的。 客观的说，引用计数算法实现简单，判定效率很高，在大部分情况下它都是一个不错的算法，但引用计数算法无法解决对象循环引用的问题。举个简单的例子：对象A和B分别有字段b、a，令A.b=B和B.a=A，除此之外这2个对象再无任何引用，那实际上这2个对

JVM详解

JVM详解 本文详细讲解了JVM(Java Virtual Machine)的方方面面,首先由java的特性来描绘JVM 的大致应用,再细细阐述了JVM的原理及内存管理机制和调优.最后讲述了与JVM密切相关的Java GC机制. 本文内容大多来自网络,但内容十分丰富,是学习JVM的好资料. 后面会再针对JVM的两大职责class loader和execution engine进行讲解 若有疑问 目录 Java相关 (2) 1.1Java定义 (2) 1.2Java的开发流程 (2) 1.3Java运行的原理 (3) 1.4半编译半解释 (4) 1.5平台无关性 (5) JVM内存模型 (5) 2.1JVM规范 (6) 2.2 Sun JVM (9) 2.3 SUN JVM内存管理(优化) (10) 2.4 SUN JVM调优 (13) 2.5.JVM简单理解 (16) 2.5.1Java栈 (16) 2.5.2堆 (16) 2.5.3堆栈分离的好处 (19) 2.5.4 堆(heap)和栈(stack) (19) JAVA垃圾收集器 (20) 3.1垃圾收集简史 (20) 3.2常见的垃圾收集策略 (20) 3.2.1Reference Counting(引用计数） (20) 3.2.2跟踪收集器 (21) 3.3JVM的垃圾收集策略 (25) 3.3.1Serial Collector (25) 3.3.2 Parallel Collector (25) 3.3.3 Concurrent Collector (26) Java虚拟机（JVM）参数配置说明 (26)

JVM知识点总览

jvm 总体梳理 jvm体系总体分四大块： 类的加载机制 jvm内存结构 GC算法垃圾回收 GC分析命令调优 类的加载机制 主要关注点： 什么是类的加载 类的生命周期 类加载器 双亲委派模型 什么是类的加载 类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个https://www.wendangku.net/doc/1a3023836.html,ng.Class对象，用来封装类在方法区内的数据结构。类的加载的最终产品是位于堆区中的Class对象，Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。 类的生命周期 类的生命周期包括这几个部分，加载、连接、初始化、使用和卸载，其中前三部是类的加载的过程,如下图； 加载，查找并加载类的二进制数据，在Java堆中也创建一个https://www.wendangku.net/doc/1a3023836.html,ng.Class类的对象 连接，连接又包含三块内容：验证、准备、初始化。1）验证，文件格式、元数据、字节码、- 符号引用验证；2）准备，为类的静态变量分配内存，并将其初始化为默认值；3）解析，把类中的符号引用转换为直接引用 初始化，为类的静态变量赋予正确的初始值 使用，new出对象程序中使用 卸载，执行垃圾回收 类加载器

启动类加载器：Bootstrap ClassLoader，负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库 扩展类加载器：Extension ClassLoader，该加载器由https://www.wendangku.net/doc/1a3023836.html,uncher$ExtClassLoader实现，它负责加载DK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如 javax.*开头的类），开发者可以直接使用扩展类加载器。 应用程序类加载器：Application ClassLoader，该类加载器由 https://www.wendangku.net/doc/1a3023836.html,uncher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器 类加载机制 全盘负责，当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入 父类委托，先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类 缓存机制，缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效 jvm内存结构 主要关注点： jvm内存结构都是什么 对象分配规则 内存结构

2020面试题总结JVM篇_一目斋

1、什么情况下会发生栈内存溢出。 在HotSpot虚拟机中是不区分虚拟机栈和本地方法栈，栈是线程私有的，它的生命周期与线程相同，每个方法在执行的时候都会创建一个栈帧，用来存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈桢在虚拟机栈中入栈到出栈的过程。本地方法栈与虚拟机栈相似，区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。 栈内存溢出是指线程请求的栈深度大于虚拟机所允许的最大深度，则将抛出StackOverflowError异常（StackOverflowError不属于OOM异常）。最有可能的原因就是方法递归产生的这种结果。 另一个可能是引用了大的变量，在拓展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常（这个属于内存溢出）。 2、JVM的内存结构，Eden和Survivor比例。 Java虚拟机在执行Java程序的过程中把它所管理的内存划分为若干个不同的数据区域，这些区域都有各自的用途。 ?程序计数器。当前线程执行的字节码的行号指示器，是线程私有的。也是唯一一个不会发生内存溢出的区域。 ?Java虚拟机栈。也是线程私有的，描述的是Java方法执行的内存模型，线程请求的栈深度大于虚拟机所允许的最大深度，则将抛出 StackOverflowError异常。

?本地方法栈。与虚拟机栈相似，区别不过是虚拟机栈为虚拟机执行Java 方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native 方法服务。 ?Java堆。是Java虚拟机中管理的内存中最大的一块，所有线程共享区域，唯一目的就是存放对象实例。所有的对象实例以及数组都要在堆上分配 内存。Java堆也是垃圾回收器管理的主要区域，也被称为gc堆，收集 器基本都采用分代收集算法，Java堆中还可以细分为：新生代和老年代。 ?方法区。所有线程共享区域，用于存储已经被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。很多人也愿意称之为 “永久代”。 ?运行时常量池。是方法区的一部分，用于存放编译器生成的各种字面量和符号引用。 ?直接内存。并不是虚拟机运行时数据区的一部分。例如NIO，它可以使用Native函数直接分配堆外内存，然后通过一个存储在Java堆中的 DirectByteBuffer对象作为这块内存的引用进行操作。这样避免了在Java 堆和Native堆中来回复制数据，提高了性能。 JVM中要对堆进行分代，分代的理由是优化GC性能，很多对象都是朝生夕死的，如果分代的话，我们把新创建的对象放到某一地方，当GC的时候先把这 块存“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。HotSpot JVM把新生代分为了三部分：1个Eden区和2个Survivor区（分别 叫from和to）。默认比例为8：1。一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年 龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。 因为年轻代中的对象基本都是朝生夕死的(80%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用 其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制 算法不会产生内存碎片。 3、JVM内存为什么要分成新生代、老年代和持久代。新生代中为什么要分Eden和Survivor。 堆内存是虚拟机管理的内存中最大的一块，也是垃圾回收最频繁的一块区域， 我们程序所有的对象实例都存放在堆内存中。给堆内存分代是为了提高对象内 存分配和垃圾回收的效率。试想一下，如果堆内存没有区域划分，所有的新创 建的对象和生命周期很长的对象放在一起，随着程序的执行，堆内存需要频繁 进行垃圾收集，而每次回收都要遍历所有的对象，遍历这些对象所花费的时间 代价是巨大的，会严重影响我们的GC效率，这简直太可怕了。 有了内存分代，情况就不同了，新创建的对象会在新生代中分配内存，经过多 次回收仍然存活下来的对象存放在老年代中，静态属性、类信息等存放在永久

Java垃圾回收机制

Java垃圾回收机制 1、引用计数：没有应用到JVM，只是理论说明。 2、活的对象：可以追溯到堆栈和静态存储区 3、Stop and copy：停止工作，将活的对象从一个堆复制到另一个堆，紧密排列，然后剩下 的就是垃圾对象了。问题：（1）空间；（2）复制：垃圾少，要复制大量活的对象 4、Mark and sweep：标记每个对象是否活对象，标记完所有对象，清楚非活的对象。问题： 空间不连续。 5、如果垃圾很少，复制效率降低的话就用，标记清扫；如果不连续空间太多的话，则转到 停止复制 6、优化方法：Just－In-Time 和HotSoft，前者翻译成本地机器码，后者惰性编译，只在必 要时编译代码，不被执行的代码不被编译，代码每次执行的时候都会做一定的优化。7、避免内存泄漏或者不当使用的方法：（1）重复使用已经初始化的对象，尽量少声明对象； （2）try catch finally语句中清楚不需要的对象；(3)执行完毕清楚不必要的对象，当然是那些引用可能被保存的对象。 尽管java虚拟机和垃圾回收机制管理着大部分的内存事务，但是在java软件中还是可能存在内存泄漏的情况。的确，在大型工程中，内存泄漏是一个普遍问题。避免内存泄漏的第一步，就是要了解他们发生的原因。这篇文章就是要介绍一些常见的缺陷，然后提供一些非常好的实践例子来指导你写出没有内存泄漏的代码。一旦你的程序存在内存泄漏，要查明代码中引起泄漏的原因是很困难的。同时这篇文章也要介绍一个新的工具来查找内存泄漏，然后指明发生的根本原因。这个工具容易上手，可以让你找到产品级系统中的内存泄漏。 垃圾回收（GC）的角色 虽然垃圾回收关心着大部分的问题，包括内存管理，使得程序员的任务显得更加轻松，但是程序员还是可能犯些错误导致内存泄漏问题。GC(垃圾回收)通过递归对所有从“根”对象(堆栈中的对象，静态数据成员，JNI句柄等等)继承下来的引用进行工作，然后标记所有可以访问的活动着的对象。而这些对象变成了程序唯一能够操纵的对象，其他的对象都被释放了。因为GC使得程序不能够访问那些被释放的对象，所以这样做是安全的。 内存管理可以说是自动的，但是这并没有让程序员脱离内存管理问题。比方说，对于内存的分配（还有释放）总是存在一定的开销，尽管这些开销对程序员来说是隐含的。一个程序如果创建了很多对象，那么它就要比完成相同任务而创建了较少对象的程序执行的速度慢（如果其他的条件都相同）。

黑马程序员 Java教程：JVM服务调优实战

JVM服务调优实战 服务器：8 cup, 8G mem e.g. java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0 调优方案： ?-Xmx5g：设置JVM最大可用内存为5G。 ?-Xms5g：设置JVM初始内存为5G。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。 ?-Xmn2g：设置年轻代大小为2G。整个堆内存大小= 年轻代大小+ 年老代大小+ 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。 ?-XX:+UseParNewGC：设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。 ?-XX: ParallelGCThreads=8：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。 ?-XX:SurvivorRatio=6：设置年轻代中Eden区与Survivor区的大小比值。根据经验设置为6，则两个Survivor区与一个Eden区的比值为2:6，一个Survivor区占整个年轻代的1/8。 ?-XX:MaxTenuringThreshold=30：设置垃圾最大年龄（次数）。如果设置为0的话，则年轻代对象不经过Survivor区直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次

垃圾回收系列(3)：CLR与JVM垃圾回收器的比较

垃圾回收系列（3）：CLR与JVM垃圾回收器的比较 发布者：TerryLee | 分类：.NET框架 | Java技术 | 计算机科学 本文为垃圾回收讲座的第三篇，在前面两篇（一、二）文章里介绍了手工管理内存带来的一些问题，以及一些经典的GC算法。本文我们主要关注微软的CLR与JVM垃圾回收器方面的比较。我们知道CLR和JVM都采用了分代式垃圾回收器，而分代式垃圾回收器则基于以下几点假设： 1. 对象越新，其生存期就越短 2. 对象越老，其生存期就越长 3. 对堆的一部分执行GC比对整个堆执行GC要快 CLR和JVM尽管都采用了分代式垃圾回收器，但是它们在很多处理方面都有些不同：分代机制，大对象堆，回收模式，回收算法，寻找存活对象效率等。 分代机制 在CLR中，对象按年龄可以分为三代：第0代、第1代、第2代，如下图所示： 在这三代之间，对象代的提升过程，大家可以参考《CLR via C#》，里面有比较详细的介绍。 JVM中对于对象的分代式新生代和旧生代：

回收模式 在CLR4.0之前，提供三种不同的垃圾回收模式：工作站并发GC、工作站非并发GC以及服务器GC，如下图所示： 工作站非并发GC模式，没有专门的GC线程，而是由工作线程负责回收，在回收过程中，需要暂时挂起应用程序，回收结束后应用程序继续运行，所以在回收过程中会有应用程序暂停现象：

工作站并发GC模式，为了解决在执行垃圾回收时引起的应用程序暂停问题，会有一个专门的GC线程负责垃圾回收，大多数时间垃圾回收都可以应用程序并发执行，但是仅仅是针对Full GC，而对于第0代、第1代对象，仍然会使用非并发模式执行，并发垃圾回收本质上牺牲了更多的CPU时间和内存来换取应用程序暂停时间的减小： 服务器GC模式运行在多CPU服务器上，如果在单CPU机器上配置了使用服务器GC，不会起任何作用，垃圾回收仍然会使用工作站非并发模式执行。服务器GC模式为每个CPU分配一个专用的垃圾回收线程和一个托管堆，并且该垃圾回收线程具有较高的优先级，在执行垃圾回收期间，应用程序工作线程会暂时挂起：

JVM内存参数详解以及配置调优

JVM的结构 从功能上分，Java虚拟机主要由六个部分组成，可以分成三类： 第一类：JVM API：就是我们最常用的Java API，它是开发人员和Java交互的入口，它主要是JAVA_HOME/jre/lib下的运行时类库rt.jar和编译相关的tools.jar 第二类：JVM内部组件 类装载器(ClassLoader)：将Byte Array的.class文件装载、链接和初始化。 内存管理(Memory Managent)：为对象分配内存，以及释放内存。后者就是垃圾回收Garbage Collector（GC）。由于JVM最复杂的、最影响性能的就是GC，所以内存管理一般就指垃圾回收。 诊断接口(Diagostics Interface)：这主要体现在JVMTI(jdk1.4下的JVMPI和JVMDI)，它主要用来诊断程序的问题和性能，一般提供给工具厂商实现。如eclispe IDE下的debug功能，Jprofiler 性能调优工具。 类解释器(Interpreter)：解释装载进虚拟机的class对象，包括JIT等特性相关。 第三类：平台相关接口(Platform Interface)：主要为了跨操作系统平台重用JVM代码，不过，它和我们开发人员关系不大。 在以上六个组件中，我们开发人员最关心的是ClassLoader和GC，用Java做系统框架、容器和它们密切相关。做业务系统时一些基础代码也和它们打交道，譬如最常用的Class.forName(),Thread.currentThread.getContextClassLoader()。我们仔细想想，为什么是上面两个问题？因为，它和我们class的整个生命周期最为相关：怎么将一个class和相关class 加载进来，class实例什么时候创建，什么时候被销毁？ 所以，下面的部分我们要专门讨论这些问题。 在JVM中有两种垃圾方式，一种叫做Minor（次收集），另一种叫做Major（主收集）。其中Minor在Young Generation的空间被对象全部占用后执行，主要是对Young Generation中的对象进行垃圾收集。而Major是针对于整个Heap size的垃圾收集。其中Minor方式的收集经常发生，并且Minor收集所占用的系统时间小。Major方式的垃圾收集则是一种“昂贵”的垃圾收集方式，因为在Major要对整个Heap size进行垃圾收集,这会使得应用停顿的时间变得较长。 java -jar -server -verbose:gc -XX:+UseParNewGC -Xmn8m -Xms32m -Xmx32m SwingSet2.jar 使用了-XX:+UseParNewGC选项的minor收集的时间要比不使用的时候优。 java -jar -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx 256m SwingSet2.jar 采用-XX:+UseConcMarkSweepGC选项在Heap Size 比较大而且Major收集时间较长的情况下使用更合适

深入JVM-垃圾收集器常用的GC参数

深入JVM-垃圾收集器常用的GC参数 1.与串行回收器相关的参数 -XX:+UseSerialGC:在新生代和老年代使用串行收集器 -XX:SurvivorRatio:设置eden区大小和survivor区大小的比例 -XX:PretenureSizeThreshold:设置大对象直接进入老年代的阈值。当对象的大小超过这个值时，将直接在老年代分配。 -XX:MaxTenuringThreshold:设置对象进入老年代的年龄的最大值。每一次Minor GC后，对象年龄就加1。任何大于这个年龄的对象，一定会进入老年代。 2.与并行GC相关的参数 -XX:+UseParNewGC:在新生代使用并行收集器 -XX:+UseParallelOldGC:老年代使用并行回收收集器 -XX:ParallelGCThreads:设置用于垃圾回收的线程数。通常情况下可以和CPU 数量相等，但在CPU数量较多的情况下，设置相对较小的数值也是合理的。-XX:MaxGCPauseMillis:设置最大垃圾收集停顿时间。他的值是一个大于0的整数。收集器在工作时，会调整Java堆大小或者其他参数，尽可能把停顿时间控制在MaxGCPauseMillis以内。 -XX:GCTimeRatio:设置吞吐量大小。它是0-100的整数。假设GCTimeRatio的值为n，那么系统将花费不超过1/(1+n)的时间用于垃圾收集。 -XX:+UseAdaptiveSizePolicy:打开自适应GC策略。在这种模式下，新生代的大小、eden和survivor的比例、晋升老年代的对象年龄等参数会被自动调整，已达到在堆大小、吞吐量和停顿时间之间的平衡点。 3.与CMS回收期相关的参数 -XX:+UseConcMarkSweepGC:新生代使用并行收集器，老年代使用CMS+串行收集器 -XX:ParallelCMSThreads:设定CMS的线程数量 -XX:CMSInitiatingOccupancyFraction:设置CMS收集器在老年代空间被使用多少后触发，默认为68% -XX:+UseCMSCompactAtFullCollection:设置CMS收集器完成垃圾收集后是否要进行一次内存碎片的整理 -XX:CMSFullGCsBeforeCompaction:设定进行多少次CMS垃圾回收后，进行一次内存压缩 -XX:+CMSClassUnloadingEnabled:允许对类元数据区进行回收

java内存泄露定位与分析

使用IBM 性能分析工具解决生产环境中的性能问题（javacore） / 2012-06-01 14:14:01 / 个人分类： / / /cn/java/j-lo-javacore/index.html 序言 企业级应用系统软件通常有着对并发数和响应时间的要求，这就要求大量的用户能在高响应时间内完成业务操作。这两个性能指标往往 决定着一个应用系统软件能否成功上线，而这也决定了一个项目最终能否验收成功，能否得到客户认同，能否继续在一个行业发展壮大 下去。由此可见性能对于一个应用系统的重要性，当然这似乎也成了软件行业的不可言说的痛——绝大多数的应用系统在上线之前， 项目组成员都要经历一个脱胎换骨的过程。 生产环境的建立包含众多方面，如存储规划、参数调整、调优、应用系统调优等等。这几方面互相影响，只有经过不断的调整优化，才 能达到资源的最大利用率，满足客户对系统吞吐量和响应时间的要求。在无数次的实践经验中，很多软件专家能够达成一致的是：应用 系统本身的优化是至关重要的，否则即使有再大的内存，也会被消耗殆尽，尤其是产生OOM（Out Of Memory）的错误的时候，它会 贪婪地吃掉你的内存空间，直到系统宕机。 内存泄露—难啃的骨头 产生OOM 的原因有很多种，大体上可以简单地分为两种情况，一种就是物理内存确实有限，发生这种情况时，我们很容易找到原因，但是它一般不会发生在实际的生产环境中。因为生产环境往往有足以满足应用系统要求的配置，这在项目最初就是根据系统要求进行购 置的。 另外一种引起OOM 的原因就是应用系统本身对资源的的不恰当使用、配置，引起内存使用持续增加，最终导致JVM Heap Memory 被耗尽，如没有正确释放JDBC 的Connection Pool 中的对象，使用Cache 时没有限制Cache 的大小等等。本文并不针对各种情 况做讨论，而是以一个项目案例为背景，探索解决这类问题的方式方法，并总结一些最佳实践，供广大开发工程师借鉴参考。 项目背景介绍 项目背景： 1. 内网用户500 人，需要同时在线进行业务操作（中午休息一小时，晚6 点下班）。 2. 生产环境采用传统的主从式，未做Cluster ，提供HA 高可用性。 3. 服务器为AIX P570，8U，16G，但是只有一半的资源，即4U，8G 供新系统使用。 项目三月初上线，此前笔者与架构师曾去客户现场简单部署过一两次，主要是软件的安装，应用的部署，测一下应用是不是能够跑起来，算作是上线前的准备。应用上线（试运行）当天，项目组全体入住客户现场，看着用户登录数不断攀升，大家心里都没有底，高峰时候 到了440，系统开始有点反应变慢，不过还是扛下来了，最后归结为目前的资源有限，等把另一半资源划过来，就肯定没问题了。（须 知增加资源，调优的工作大部分都要重新做一遍，系统级、数据库级等等，这也是后面为什么建议如果资源可用，最好一步到位的原因。）

jvm垃圾回收调整

1JVM的垃圾回收机制详解和调优 3.Sun HotSpot 1.4.1 JVM堆大小的调整 3.Sun HotSpot 1. 4.1 JVM堆大小的调整 Sun HotSpot 1.4.1使用分代收集器，它把堆分为三个主要的域：新域、旧域以及永久域。Jvm生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环后，便获得使用期并进入旧域。在永久域中jvm则存储class 和method对象。就配置而言，永久域是一个独立域并且不认为是堆的一部分。 下面介绍如何控制这些域的大小。可使用-Xms和-Xmx 控制整个堆的原始大小或最大值。 下面的命令是把初始大小设置为128M： java –Xms128m –Xmx256m为控制新域的大小，可使用-XX:NewRatio设置新域在堆中所占的比例。 下面的命令把整个堆设置成128m，新域比率设置成3，即新域与旧域比例为1：3，新域为堆的1/4或32M： java –Xms128m –Xmx128m –XX:NewRatio =3可使用-XX:NewSize和-XX:MaxNewsize设置新域的初始值和最大值。 下面的命令把新域的初始值和最大值设置成64m: java –Xms256m –Xmx256m –Xmn64m 永久域默认大小为4m。运行程序时，jvm会调整永久域的大小以满足需要。每次调整时，jvm会对堆进行一次完全的垃圾收集。 使用-XX:MaxPerSize标志来增加永久域搭大小。在WebLogic Server应用程序加载较多类时，经常需要增加永久域的最大值。当jvm加载类时，永久域中的对象急剧增加，从而使jvm不断调整永久域大小。为了避免调整，可使用 -XX:PerSize标志设置初始值。 下面把永久域初始值设置成32m，最大值设置成64m。 java -Xms512m -Xmx512m -Xmn128m -XX:PermSize=32m -XX:MaxPermSize=64m 默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden，用于生成新的对象。另两部分称为救助空间，当Eden 充满时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助空间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它