eden

学习-JVM命令

谁说胖子不能爱 提交于 2019-12-10 12:22:19
jstat jstat (JVM statistics Monitoring)是用于监视虚拟机运行时状态信息的命令,它可以显示出虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。 格式: jstat [option] LVMID [interval] [count] 参数: [option] : 操作参数 class : class loader的行为统计 compiler : HotSpt JIT编译器行为统计 gc : 垃圾回收堆的行为统计 gccapacity : 各个垃圾回收代容量(young,old,perm)和他们相应的空间统计 gcutil : 垃圾回收统计概述 gccause : 垃圾收集统计概述(同-gcutil),附加最近两次垃圾回收事件的原因 gcnew : 新生代行为统计 gcnewcapacity : 新生代与其相应的内存空间的统计 gcold : 年老代和永生代行为统计 gcoldcapacity : 年老代行为统计 gcpermcapacity : 永生代行为统计 printcompilation : HotSpot编译方法统计 LVMID : 本地虚拟机进程ID [interval] : 连续输出的时间间隔 [count] : 连续输出的次数 option 参数详解 -class 监视类装载、卸载数量、总空间以及耗费的时间 $ jstat

扒一扒JVM的垃圾回收机制,下次面试你准备好了吗

余生长醉 提交于 2019-12-08 11:14:35
如果想了解Java内存模型参考: jvm内存模型-和内存分配以及jdk、jre、jvm是什么关系(阿里,美团,京东) 相信和小编一样的程序猿们在日常工作或面试当中经常会遇到JVM的垃圾回收问题,有没有在夜深人静的时候详细捋一捋JVM垃圾回收机制中的知识点呢?没时间捋也没关系,因为小编接下来会给你捋一捋。 一、 技术背景你要了解吧 二、 哪些内存需要回收? 2.1 引用计数算法 2.1.1 算法分析 2.1.2 优缺点 2.1.3 是不是很无趣,来段代码压压惊 2.2 可达性分析算法 2.3 Java中的引用你了解多少 2.4 对象死亡(被回收)前的最后一次挣扎 2.5 方法区如何判断是否需要回收 三、常用的垃圾收集算法 3.1 标记-清除算法 3.2 复制算法 3.3 标记-整理算法 3.4 分代收集算法 3.4.1 年轻代(Young Generation)的回收算法 3.4.2 年老代(Old Generation)的回收算法 3.4.3 持久代(Permanent Generation)的回收算法 四、常见的垃圾收集器 五、GC是什么时候触发的(面试最常见的问题之一) 5.1 Scavenge GC 5.2 Full GC 结束语 一、 技术背景你要了解吧   按照套路是要先装装X,谈谈JVM垃圾回收的前世今生的。说起垃圾回收(GC)

窥探JVM内存分配和回收的过程

百般思念 提交于 2019-12-07 12:08:35
一、环境 JDK 垃圾收集器 是否启用TLAB 通用JVM参数(堆内存分配见下图) 1.6.0_65 Serial + Serial Old 否 -Xms20m -Xmx20m -Xmn10m -XX:SurvivorRatio=8 二、说明 Minor GC 发生在 新生代 ,当 Eden 区域没有足够空间进行分配 Java对象大多具有 短命 的特性 Minor GC 非常频繁 ,速度也比较 快 Major GC / Full GC 发生在老年代 出现Major GC, 经常 伴随至少一次Minor GC SpeedOf (Minor GC) ≈ 10 * SpeedOf (Major GC) 三、示例 1. 对象优先分配在 Eden区 1.1 说明 新对象,优先考虑分配在 Eden 区域 如果Eden区域没有 足够的空间 容纳新对象,进行GC 如果老年代有 足够的连续空间 用来存储所有新生代对象(或历次晋升的平均大小) ⇒ Minor GC 如果对象太大,以至于 Survivor 区域 无法容纳 ,对象直接晋升到 老年代 否则使用复制算法, 复制 到Survivor区域 否则 ⇒ 先进行一次 Minor GC ,若仍不满足上述条件,进行 Full GC 若 Full GC 后依然内存不足, 1.2 代码 # 代码 public class TestAllocation {

jvm(十二):相关参数

╄→гoц情女王★ 提交于 2019-12-06 16:51:19
堆栈空间配置 JVM 中最重要的一部分就是堆空间了,基本上大多数的线上 JVM 问题都是因为堆空间造成的 OutOfMemoryError。因此掌握 JVM 关于堆空间的参数配置对于排查线上问题非常重要。 tips:本文所有配置,如无特别说明,均基于JDK1.8。 堆配置 我们使用 -Xms 设置堆的初始空间大小,使用 -Xmx 设置堆的最大空间大小。 java -Xms20m -Xmx30m GCDemo 在上面的命令中,我们设置 JVM 的初始堆大小为 20M,最大堆空间为 30M。 年轻代 在 JDK1.8 中,堆分为年轻代和老年代。JVM 提供了参数 -Xmn 来设置年轻代内存的大小,但没有提供参数设置老年代的大小。但其实老年代的大小就等于堆大小减去年轻代大小。 java -Xms20m -Xmn10M GCDemo 上面的命令中,我们设置 JVM 堆初始大小为20M。其中年轻代的大小为 10M,那么剩下的就是老年代的大小,有 10M了。 我们可以给上述命令加上 -XX:+PrintGCDetails 参数来查看内存区域的分配信息。 如上图所示,我们可以看到老年代的大小为 10M。 Eden区 在年轻代中,分为三个区域,分别是:eden 空间、from 空间、to 空间。如果要设置这部分的大小,那么就使用 -XX:SurvivorRatio 这个参数,该参数设置 eden

JVM-4-堆内存划分

孤者浪人 提交于 2019-12-06 06:38:03
什么是堆内存划分 Java虚拟机根据对象存活的周期不同,把堆内存划分为几块, 一般分为新生代、老年代和永久代,这就是JVM的内存分代策略。(JDK 1.8之后将最初的永久代取消了,由元空间取代) 为什么要分代? 堆内存是虚拟机管理的内存中最大的一块,也是垃圾回收最频繁的一块区域,我们程序所有的对象实例都存放在堆内存中。给堆内存分代是为了提高对象内存分配和垃圾回收的效率。试想一下,如果堆内存没有区域划分,所有的新创建的对象和生命周期很长的对象放在一起,随着程序的执行,堆内存需要频繁进行垃圾收集,而每次回收都要遍历所有的对象,遍历这些对象所花费的时间代价是巨大的,会严重影响我们的GC效率,这简直太可怕了。 有了内存分代,情况就不同了,新创建的对象会在新生代中分配内存,经过多次回收仍然存活下来的对象存放在老年代中,静态属性、类信息等存放在永久代中,新生代中的对象存活时间短,只需要在新生代区域中频繁进行GC,老年代中对象生命周期长,内存回收的频率相对较低,不需要频繁进行回收,永久代中回收效果太差,一般不进行垃圾回收,还可以根据不同年代的特点采用合适的垃圾收集算法。分代收集大大提升了收集效率,这些都是内存分代带来的好处 如何进行内存分代划分 Java虚拟机将堆内存划分为新生代、老年代和永久代,永久代是HotSpot虚拟机特有的概念 在JDK 1.7中HotSpot已经开始了“去永久化”

垃圾回收算法

南笙酒味 提交于 2019-12-04 15:22:27
这里主要是阐明各算法的实现思想,而不去细论算法的具体实现 标记—清除算法(Mark-Sweep) 标记—清除算法是最基础的收集算法 ,它分为“ 标记 ”和“ 清除 ”两个阶段:首先标记出所需回收的对象,在标记完成后统一回收掉所有被标记的对象, 它的标记过程其实就是前面的可达性分析算法中判定垃圾对象的标记过程 。标记—清除算法的执行情况如下图所示: 回收前状态 回收前 回收后状态 回收后 该算法有如下缺点: 标记和清除过程的 效率都不高 标记清除后会产生大量不连续的 内存碎片 ,空间碎片太多可能会导致,当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不触发另一次垃圾收集动作 复制算法(Copy) 复制算法是针对标记—清除算法的缺点,在其基础上进行改进而得到的,它将可用内存按容量分为大小相等的两块,每次只使用其中的一块, 当这一块的内存用完了,就将还存活着的对象复制到另外一块内存上面,然后再把已使用过的内存空间一次清理掉 。复制算法有如下优点: 每次只对一块内存进行回收,运行高效 只需移动栈顶指针,按顺序分配内存即可,实现简单 内存回收时不用考虑内存碎片的出现 它的缺点是:可一次性分配的 最大内存缩小了一半 复制算法的执行情况如下图所示: 回收前状态 回收前状态 回收后状态 回收后状态 现在的商业虚拟机都采用这种收集算法来回收新生代,新生代中的对象98%都是

java 垃圾回收机制

空扰寡人 提交于 2019-12-04 04:45:23
垃圾收集 GC (Garbage Collection)是Java语言的核心技术之一, 在Java中,程序员不需要去关心内存动态分配和垃圾回收的问题,这一切都交给了 JVM 来处理。 一. jvm的内存结构 垃圾回收都是基于内存去回收的,因此,先要对内存结构有一个大概的了解 Java内存运行时区域大概分了三部分 其中PC寄存器、java虚拟机栈、本地方法栈3个区域是所有线程独有的一块区域,随线程而生,随线程而灭。栈中的栈帧随着方法的进入和退出而有条不紊地执行着入栈和出栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的,因此这几个区域的内存分配和回收都具备确定性,在这几个区域内就不需要过多考虑回收的问题,因为方法结束或者线程结束,内存自然就跟随着回收了。 而Java堆和方法区则不一样,一个接口中的多个实现类需要的内存可能不一样,一个方法中的多个实现类需要的内存可能不一样,一个方法中的多个分支需要的内存也可能不一样,只有在程序处于运行期间时才能知道会创建哪些对象,这部分内存的分配和回收是动态的,垃圾收集关注的是这部分的内存。 二 . 内存分配 在解垃圾回收之前,得先了解JVM是怎么分配内存的,然后识别哪些内存 是垃 圾需要回收,最后才是用什么方式回收。 Java的内存分配原理与C/C++不同,C/C++每次申请内存时都要malloc进行系统调用,而系统调用发生在内核空间

为什么新生代内存需要有两个Survivor区

核能气质少年 提交于 2019-12-03 20:22:07
为什么新生代内存需要有两个Survivor区 为什么要有Survivor区 先不去想为什么有两个Survivor区,第一个问题是,设置Survivor区的意义在哪里? 如果没有Survivor,Eden区每进行一次Minor GC,存活的对象就会被送到老年代。老年代很快被填满,触发Major GC(因为Major GC一般伴随着Minor GC,也可以看做触发了Full GC)。老年代的内存空间远大于新生代,进行一次Full GC消耗的时间比Minor GC长得多。你也许会问,执行时间长有什么坏处?频发的Full GC消耗的时间是非常可观的,这一点会影响大型程序的执行和响应速度,更不要说某些连接会因为超时发生连接错误了。 好,那我们来想想在没有Survivor的情况下,有没有什么解决办法,可以避免上述情况: 方案 优点 缺点 增加老年代空间 更多存活对象才能填满老年代。降低Full GC频率 随着老年代空间加大,一旦发生Full GC,执行所需要的时间更长 减少老年代空间 Full GC所需时间减少 老年代很快被存活对象填满,Full GC频率增加 显而易见,没有Survivor的话,上述两种解决方案都不能从根本上解决问题。 我们可以得到第一条结论:Survivor的存在意义,就是减少被送到老年代的对象,进而减少Full GC的发生,Survivor的预筛选保证

[转载]深入理解Java垃圾回收机制

ぃ、小莉子 提交于 2019-12-03 10:56:56
深入理解Java垃圾回收机制 2016-07-28 20:07:49 湖冰2019 阅读数 14607 更多 分类专栏: JAVA基础 原文: http://www.linuxidc.com/Linux/2015-06/118829.htm 一、垃圾回收机制的意义   Java语言中一个显著的特点就是引入了垃圾回收机制,使c++程序员最头疼的内存管理的问题迎刃而解,它使得Java程序员在编写程序的时候不再需要考虑内存管理。由于有个垃圾回收机制,Java中的对象不再有“作用域”的概念,只有对象的引用才有“作用域”。垃圾回收可以有效的防止内存泄露,有效的使用空闲的内存。   ps:内存泄露是指该内存空间使用完毕之后未回收,在不涉及复杂数据结构的一般情况下,Java 的内存泄露表现为一个内存对象的生命周期超出了程序需要它的时间长度,我们有时也将其称为“对象游离”。 二、垃圾回收机制中的算法   Java语言规范没有明确地说明JVM使用哪种垃圾回收算法,但是任何一种垃圾回收算法一般要做2件基本的事情:(1)发现无用信息对象;(2)回收被无用对象占用的内存空间,使该空间可被程序再次使用。   1.引用计数法(Reference Counting Collector) 1.1算法分析    引用计数是垃圾收集器中的早期策略。在这种方法中,堆中每个对象实例都有一个引用计数。当一个对象被创建时

Old Gen heap is full and the Eden and Survivor are low and almost empty

匿名 (未验证) 提交于 2019-12-03 02:49:01
可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试): 问题: A production environment became very slow recently. The cpu of the process took 200%. It kept working however. After I restarted the service it functioned normal again. I have several symptoms : The Par survivor space heap was empty for a long time and garbage collection took about 20% of the cpu time. JVM options: X:+CMSParallelRemarkEnabled, -XX:+HeapDumpOnOutOfMemoryError, -XX:+UseConcMarkSweepGC, - XX:+UseParNewGC, -XX:HeapDumpPath=heapdump.hprof, -XX:MaxNewSize=700m, -XX:MaxPermSize=786m, -XX:NewSize=700m, -XX:ParallelGCThreads=8, -XX