gc

java性能优化 –gc日志收集与分析

China☆狼群 提交于 2020-04-26 17:22:09
使用jvisualvm与jconsole能够实时监控java程序的运行状态。 但是我们并不会一直盯着输入屏幕,或者说开着一个客户端一直抓取服务器的运行信息。相对来说,能够让java程序在运行的时候自动生成日志,然后我们再对生成的数据进行分析是比较不错的选择。 收集日志 打印Gc日志的参数 打印gc详细信息 -XX:+PringGCDetails 带有距离JVM开始运行的时间戳 -XX:+PrintGCTimeStamps 带有日历时间戳 --XX:+PringGCDateStamps 指定gc日志存放文件(不指定则控制台打印) -Xloggc: 针对高延迟问题调优HotSpot VM时,下面两个命令行选项特别有用,通过它们可以获得应用程序由于执行VM安全操作而阻塞的时间以及两个安全点操作之间应用程序运行的时间。 -XX:+PrintGCApplicationStoppedTime-XX:+PrintGCApplicationConcurrentTime 何谓安全操作:安全操作使JVM进入到一种状态:所有的java应用线程都被阻塞、执行本地代码的线程都被禁止返回VM执行 Java 代码。安全操作常用于虚拟机需要进行内部操作时,此时所有的 Java 线程都被显式地置于阻塞状态且不能修改 Java 堆的情况。 设置参数 Tomcat $CATALINA_HOME/bin/setenv

成为JavaGC专家(2)—如何监控Java垃圾回收机制

六月ゝ 毕业季﹏ 提交于 2020-04-25 08:00:38
本文是成为Java GC专家系列文章的第二篇。在第一篇《 深入浅出Java垃圾回收机制 》中我们学习了不同GC算法的执行过程,GC是如何工作的,什么是新生代和老年代,你应该了解的JDK7中的5种GC类型,以及这5种类型对于应用性能的影响。 在本文中,我将解释 JVM到底是如何执行垃圾回收处理的 。 什么是GC监控? 垃圾回收收集监控 指的是搞清楚JVM如何执行GC的过程,例如,我们可以查明: 1. 何时一个新生代中的对象被移动到老年代时,所花费的时间。 2. Stop-the-world 何时发生的,持续了多长时间。 GC监控是为了鉴别JVM是否在高效地执行GC,以及是否有必要进行额外的性能调优。基于以上信息,我们可以修改应用程序或者调整GC算法(GC优化)。 如何监控GC 有很多种方法可以监控GC,但其差别仅仅是GC操作通过何种方式展现而已。GC操作是由JVM来完成,而GC监控工具只是将JVM提供的GC信息展 现给你,因此,不论你使用何种方式监控GC都将得到相同的结果。所以你也就不必去学习所有的监控GC的方法。但是因为学习每种监控方法不会占用太多时间, 了解多一点可以帮助你根据不同的场景选择最为合适的方式。 下面所列的工具以及JVM参数并不适用于所有的HVM供应商。这是因为并没有关于GC信息的强制标准。本文我们将使用HotSpot JVM (Oracle JVM)。因为NHN

python immutable 与mutable

為{幸葍}努か 提交于 2020-03-05 22:59:08
在使用 help topics classes 看到 immutable 与mutable 1、immutable类型有 number string tuple unicode frozenset 2、mutable类型 list dict set immutable类型会重新申请内存,类型ID是不同的 >>> a = 1 >>> id(a) 140383443029032 >>> a = 2 >>> id(a) 140383443029008 >>> type(a) <type 'int'> >>> 来源: oschina 链接: https://my.oschina.net/u/272337/blog/495867

Partial GC、Minor GC/Young GC、Major GC/Old GC、Mixed GC、Full GC 的含义,详见书籍《深入理解Java虚拟机(第3版)》第77页

时光怂恿深爱的人放手 提交于 2020-03-01 21:37:59
Partial GC、Minor GC/Young GC、Major GC/Old GC、Mixed GC、Full GC 的含义,详见书籍《深入理解Java虚拟机(第3版)》第77页 来源: https://www.cnblogs.com/cag2050/p/12392109.html

深入理解java的finalize

走远了吗. 提交于 2020-03-01 01:24:00
基本预备相关知识 1 java的GC只负责内存相关的清理,所有其它资源的清理必须由程序员手工完成。要不然会引起资源泄露,有可能导致程序崩溃。 2 调用GC并不保证GC实际执行。 3 finalize抛出的未捕获异常只会导致该对象的finalize执行退出。 4 用户可以自己调用对象的finalize方法,但是这种调用是正常的方法调用,和对象的销毁过程无关。 5 JVM保证在一个对象所占用的内存被回收之前,如果它实现了finalize方法,则该方法一定会被调用。Object的默认finalize什么都不做,为了效率,GC可以认为一个什么都不做的finalize不存在。 6 对象的finalize调用链和clone调用链一样,必须手工构造。 如 Java代码 protected void finalize() throws Throwable { super .finalize(); } 对象的销毁过程 在对象的销毁过程中,按照对象的finalize的执行情况,可以分为以下几种,系统会记录对象的对应状态: unfinalized 没有执行finalize,系统也不准备执行。 finalizable 可以执行finalize了,系统会在随后的某个时间执行finalize。 finalized 该对象的finalize已经被执行了。 GC怎么来保持对finalizable的对象的追踪呢

fullgc过于频繁该怎么解决?(问题8)

落花浮王杯 提交于 2020-02-29 17:01:02
fullgc过于频繁有可能会造成oom,有可能不会。 首先明确一下,这篇文章的重点是分析后面一种情况,即应用在频繁的fullgc,但并没有出现oom。 我们来想一下为什么会出现fullgc,触发原因有很多种,但归根到底都是因为内存空间不足了(system.gc的情况不考虑)。 系统在频繁的fullgc,但并没有出现oom,说明每次回收的时候,肯定清理了部分内存空间。那这里就有2种情况,gc之后清理的内存空间大不大? 1、如果每次gc之后剩余的空间不大,说明有一部分顽固对象一直没法被回收,导致可用内存变少。这种情况下很容易后续出现oom,比如说一次大对象的申请 2、如果每次gc之后剩余的空间比较大,意味着大部分对象都被清理了,但是系统又在频繁的fullgc,说明很快老年代又会涌入大量对象。这个时候就应该检查下jvm的参数配置,很有可能是新生代设置的太小了,导致很多应该在minor gc阶段就清理出去的对象留到了老年代,这种可能性是最大的 新生代可以分为eden、survivor0、survivor1,正常的对象分配都是在eden完成的,如果eden空间不够了,会触发一次minor gc,存活的对象放在s0或s1中。随着每次minor gc,存活的对象会不断的从s0迁到s1,再从s1迁到s0,这个过程经过几次之后,如果对象还是存活的,就会晋升到老年代。 但如果新生代大小设置的太小

java中的内存模型

独自空忆成欢 提交于 2020-02-28 16:05:23
概述 在java中应为不同的目的可以将java划分为两种内存模型:gc内存模型。并发内存模型。 gc内存模型 java与c++之间有一堵由内存动态分配与垃圾收集技术所围成的“高墙”。墙外面的人想进去,墙里面的人想出来。 java在执行java程序的过程中会把它管理的内存划分若干个不同功能的数据管理区域。如图: 整体上。分为三部分:栈,堆,程序计数器,他们每一部分有其各自的用途;虚拟机栈保存着每一条线程的执行程序调用堆栈;堆保存着类对象、数组的具体信息;程序计数器保存着每一条线程下一次执行指令位置。这三块区域中栈和程序计数器是线程私有的。也就是说每一个线程拥有其独立的栈和程序计数器。我们可以看看具体结构: 虚拟机/本地方法栈 在栈中,会为每一个线程创建一个栈。线程越多,栈的内存使用越大。对于每一个线程栈。当一个方法在线程中执行的时候,会在线程栈中创建一个栈帧(stack frame),用于存放该方法的上下文(局部变量表、操作数栈、方法返回地址等等)。每一个方法从调用到执行完毕的过程,就是对应着一个栈帧入栈出栈的过程。 本地方法栈与虚拟机栈发挥的作用是类似的,他们之间的区别不过是虚拟机栈为虚拟机执行java(字节码)服务的,而本地方法栈是为虚拟机执行native方法服务的。 方法区/堆 在hotspot的实现中,方法区就是在堆中称为永久代的堆区域。几乎所有的对象/数组的内存空间都在堆上

Full GC 和 Minor GC

一个人想着一个人 提交于 2020-02-11 12:15:59
目录 Full GC Full GC的触发条件 Minor GC 触发条件 Minor GC的过程 Survivor区对象晋升位老年代对象的条件 Minor GC的问题与卡表分析 关于 Major GC的说明 小结 参考资料 & 鸣谢 Full GC Full GC 就是收集整个堆,包括新生代,老年代,永久代(在JDK 1.8及以后,永久代会被移除,换为metaspace)等收集所有部分的模式 RednaxelaFX大 在 Major GC和Full GC的区别是什么?触发条件呢?- 知乎 这个问题有关于 GC分类的回答: 针对 HotSpot VM的实现,它里面的GC其实准确分类有两种: Partial GC(局部 GC) : 并不收集整个 GC 堆的模式 Young GC: 只收集 young gen 的 GC, Young GC 还有种说法就叫做 "Minor GC" Old GC: 只收集 old gen 的 GC。只有垃圾收集器 CMS 的 concurrent collection 是这个模式 Mixed GC: 收集整个 young gen 以及部分 old gen 的 GC。只有垃圾收集器 G1 有这个模式 Full GC : 收集整个堆,包括 新生代,老年代,永久代(在 JDK 1.8及以后,永久代被移除,换为metaspace 元空间)等所有部分的模式 Full

JVM调优之---一次GC调优实战

泄露秘密 提交于 2020-02-01 03:11:48
某系统反馈『性能抖动,响应时间会突然飙高,TP999 MAX会到3000+』,初步怀疑是JVM FULL GC导致的 STW,观察FULL GC日志默认的JVM参数: -Xms4096m -Xmx4096m -XX:PermSize=512M -XX:MaxPermSize=512M -XX:ReservedCodeCacheSize=1024M -XX:+UseCodeCacheFlushing 从线上down下来的GC LOG如下: 1768.617: [GC [PSYoungGen: 1313280K->31072K(1341440K)] 3990240K->2729238K(4137984K), 0.0992420 secs] [Times: user=0.36 sys=0.01, real=0.10 secs] 1770.525: [GC [PSYoungGen: 1316704K->27632K(1345536K)] 4014870K->2750306K(4142080K), 0.0552640 secs] [Times: user=0.20 sys=0.00, real=0.06 secs] 1772.437: [GC [PSYoungGen: 1319408K->51424K(1343488K)] 4042082K->2795338K(4140032K), 0

关于checkout android4.0.3源码Exited sync due to gc...

时光怂恿深爱的人放手 提交于 2019-12-07 17:14:30
关于checkout android4.0.3源码Exited sync due to gc errors的问题 我的源码已经下载完成了,但是为什么当前文件夹下只有一部分文件显示了,还有一部分没有呢,checkout 的时候还报错 从网上搜索说是要更新git的版本,那个网址现在也不记得了,下面是我昨天下午的操作步骤,关键的就这几步 所以我就更新了git的版本,我一开始的版本是1.7.0.4,网上最高的版本是1.8.0.0好像,但是我没敢用啊,下来了git-1.7.12.2版本的(http://code.google.com/p/git-core/downloads/list) 下载了 git-1.7.12.2.tar.gz git-htmldocs-1.7.12.2.tar.gz git-manpages-1.7.12.2.tar.gz 解压第一个,将后面两个放到第一文件夹中,然后解压 ./autoconf ./configure --prefix=/usr make make install -->root用户 git --version查看版本信息 如果报错 make: *** [po/build/locale/is/LC_MESSAGES/git.mo] Error 127 解决 sudo apt-get install smarty-gettext make: ***