Gc

起初没有人在意这场GC,直到它影响到了每一天!前言本文记录了一次排查FullGC导致的TP99过高过程,介绍了一些排查时思路,线索以及工具的应用,心愿可能帮忙一些老手在排查问题没有很好的思路时,提供一些思路,让小白也能轻松解决FullGC问题,文中理论提到的参数配置不肯定适宜其余业务场景,在调优本人的我的项目时还是须要理论试验过能力得出最佳参数配置 我也是小白,如有不合理的中央,欢送大佬们进行斧正 因为线上服务器,咱们大部分是没有SSH权限的,没有方法间接执行命令获取容器信息,所以排查过程中只能借助平台提供的工具,平台提供的工具还是挺全的,本文次要用到的工具有: JDOS容器智能监控,JDOS过程查问,SGM容器监控信息,SGM办法调用查问 以下几个工具简略介绍: http://sgm-server.jd.com/http://jagile.jd.com/jdosCD/jdt/appsJDOS容器智能监控: 查看容器的CPU,内存,磁盘,IO等信息JDOS过程查问: 查看Java过程编号,执行罕用的Java内存过程查看命令SGM容器监控信息: 查看JVM虚拟机内存变更历史记录SGM办法调用查问: 查看某一次要害接口调用的高低依赖,工夫散布起因 - 偶然呈现接口超时一开始偶然会收到报警邮件,显示有些接口调用工夫比拟长,抽查了一些接口,发现大部分都是调用上游JSF工夫比拟长,导致响应比较慢,这时候就没太在意,接下来持续察看了几天,发现一个法则,大部分邮件都是每天10点 排查定位问题首先确认了10点这个工夫点有没有定时工作之类的操作,通过询问确定这个工夫点是仓库出库高峰期,导致业务量呈现峰值(调用质变大可能是激发FullGC问题,成为问题暴漏的导火线)第二部就是确认是数据库起因,还是业务代码,还是JSF上游接口达到极限起因,到这一步还是未知的,在这用到了SGM的接口调用查问工具,下图中咱们看到,这次调用JSF也是挺高的(这个没有太好方法,除非让上游优化,所以临时疏忽),然而还有一个是logic,这个就是逻辑解决,如果没有那个FullGC提醒,就须要去剖析代码的解决是否有问题,这通过那行红色字体的提醒,很显然咱们确定了是FullGC导致的问题咱们去查看一下容器的FullGC状况,的确发现这个工夫点的FullGC特地频繁,到此曾经把问题范畴定位到就是FullGC导致的 FullGC问题排查Full GC 触发条件：到这里咱们须要确定一个问题 : “触发FullGC的条件是什么？”，老手能够去博客搜寻，当然最好是能记住这个知识点。留神这不是确定“什么起因导致的FullGC？”，因为这个问题起因太多了，咱们要一步一步排查。 上面是我查到的材料，粘到这里供参考. Minor GC触发条件：当Eden区满时，触发Minor GC。Full GC触发条件：（1）调用System.gc()时，零碎倡议执行Full GC，然而不必然执（2）老年代空间有余（3）办法区空间有余（4）通过Minor GC后进入老年代的均匀大小大于老年代的可用内存（5）由Eden区、From Space区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代这里在代码中并没有找到System.gc()的显示调用,个别咱们也不会调用这个办法,所以咱们间接看第二种状况,到SGM中查看老年代变动,后果发现老年代频繁达到90%,而这个工夫正好能够跟下面GC工夫对上. 对象进入老年代的几种状况咱们都晓得,老年代的对象应该是存活工夫很长的对象,然而咱们发现这些对象都在FullGC时被开释掉了,他们为什么到了老年代呢? 这时候咱们须要确定的第二个问题是:“什么状况下对象会进入老年代？” 查资料后有以下几种状况 年龄够了: 躲过15次(默认配置是15次) minorGC 之后从新生代进入老年代；大对象: 大对象间接进入老年代。有一个 JVM 参数 '-XX:PretenureSizeThreshold' 设置值为字节数，创立超过该大小的对象间接进入老年代,如果没有配置这个参数,这个值如同默认是1M。动静年龄判断：以后放对象的 Survivor 区，雷同年龄的一批对象（以及小于该年龄）的总内存大于该区的内存的50%，大于该年龄的其余老对象，就会进入老年代（例如1,2,3岁年龄的对象占了 S 区的50%以上，就会把大于3岁的对象挪动到老年代去。所以尽量让 S 区中的对象，占比尽量少于 50%）；剩的总量太多: Eden 区存活对象太多，超过了 Survivor 的大小，就间接把这些对象都转移到老年代去。（JDK1.8 空间担保机制）首先剖析第一种状况,如果呈现大批量这样的对象,代码中呈现了长时间援用(例如:动态Map只加不删),然而咱们能够看到,这些对象在每次FullGC都被开释掉了,阐明这批对象存活的工夫并不长, 而且代码排查也没发现这种代码,临时排除这种状况(这的代码因为是工具包的代码,所以没有太深纠,这为续集留个伏笔). 第二种状况,大对象,咱们到JDOS下载下来JMap-dump内存快照和JMap-Histo对象统计信息,通过对FullGC钱dump剖析,联合GC前GC后对象统计后果,并没有发现大量的大对象,这个根本也排除 通过JMAT(Eclipse Memory Analysis Tools)导入dump文件进行剖析，内存透露问题个别咱们间接选Leak Suspects即可，mat给出了内存透露的倡议。另外也能够抉择Top Consumers来查看最大对象报告。和线程相干的问题能够抉择thread overview进行剖析。除此之外就是抉择Histogram类概览来本人缓缓剖析，大家能够搜搜mat的相干教程。 接下来就是第三种和第四种状况,这时候咱们须要取查看年老代三块区域的变动,尤其是Survivor区域,下图是过后一个状况,S区大小始终在变动,而且基本一致放弃在50%以上,这时候想到了一个JVM高版本个性,会主动关上UseAdaptiveSizePolicy(动静调整),查资料后发现,好多人反馈这个参数会导致对象跨过S区,间接跑到老年代的状况,咱们看到在调用量继续很高的状况,尽然调整到了17M,这必定会导致包容不下过后存活的对象 UseAdaptiveSizePolicy开关参数-XX:+UseAdaptiveSizePolicy是一个开关参数，当这个参数关上之后，虚构机会依据以后零碎的运行状况收集性能监控信息，动静调整这些参数以提供最合适的进展工夫或最大的吞吐量，这种调节形式称为GC自适应的调节策略（GC Ergonomics）。 ...

1 前言垃圾回收器的暂停问题始终是Java工程师关注的重点，特地是对实时响应要求较高的服务来说，CMS和G1等支流垃圾回收器的数十毫秒乃至上百毫秒的暂停工夫相当致命。此外，调优门槛也绝对较高，须要对垃圾回收器的外部机制有肯定的理解，才可能进行无效的调优。为了解决此类问题，JDK 11开始推出了一种低提早垃圾回收器ZGC。ZGC应用了一些新技术和优化算法，能够将GC暂停工夫管制在10毫秒以内，而在JDK 17的加持下，ZGC的暂停工夫甚至能够管制在亚毫秒级别！ 2 ZGCZGC相干介绍、原理，网上曾经有很多相似文章，这里只做简略介绍。 2.1 设计指标ZGC 最后在 JDK 11 中作为试验性功能引入，并在 JDK 15 中发表为生产就绪。作为一款低提早垃圾收集器，旨在满足以下指标： 8MB到16TB的堆大小反对10ms最大GC临时最蹩脚的状况下吞吐量会升高15%（低延时换吞吐量很值，吞吐量扩容即可解决） 2.2 ZGC 内存散布ZGC与传统的CMS、G1不同、它没有分代的概念，只有相似G1的Region概率，ZGC 的 Region能够具备如下图所示的大中下三类容量： 小型 Region（Small Region）：容量固定为2MB，用于搁置小于 256KB的小对象。中型 Region（Medium Region）：容量固定为 32MB，用于搁置大于 256KB然而小于 4MB的对象。大型 Region（Large Region）：容量不固定，能够动态变化，但必须为 2MB的整数倍，用于搁置 4MB或以上的大对象。每个大型 Region中会寄存一个大对象，这也预示着尽管名字叫“大型 Region”，但它的理论容量齐全有可能小于中型Region，最小容量可低至4MB。大型 Region在ZGC的实现中是不会被重调配的（重调配是ZGC的一种解决动作，用于复制对象的收集器阶段）因为复制大对象的代价十分高。 2.3 GC工作过程与CMS中的ParNew和G1相似，ZGC也采纳标记-复制算法，不过ZGC通过着色指针和读屏障技术，解决了转移过程中精确拜访对象的问题，在标记、转移和重定位阶段简直都是并发执行的，这是ZGC实现进展工夫小于10ms指标的最要害起因。 从上图中能够看出，ZGC只有三个STW阶段：初始标记，再标记，初始转移。具体转移过程，网上有大量相似文章，这里不做具体介绍，大家有趣味能够参考以下文章： 新一代垃圾回收器ZGC的摸索与实际ZGC 最新一代垃圾回收器 | 程序员进阶 3 为什么抉择JDK17呢？JDK 17于9月14日公布，是一个长期反对（LTS）版本，这意味着它将在很多年内失去反对和更新。这也是第一个LTS版本，其中蕴含了一个可用于生产环境的ZGC版本。回顾一下，ZGC的试验版本曾经蕴含在JDK 11（之前的LTS版本）中，而第一个可用于生产环境的ZGC版本呈现在JDK 15（一个非LTS版本）中。 4 降级过程从JDK8+G1降级到JDK17+ZGC，次要是在代码层面和JVM启动参数层面的做适配。 4.1 JDK下载首先jdk17抉择的是openjdk，下载地址：https://jdk.java.net/archive/，抉择版本17 GA 4.2 代码适配JDK11移除了 Java EE and CORBA 的模块我的项目中如果用到javax.annotation.、javax.xml.等等结尾的包，须要手动引入对应依赖 <dependency> <groupId>javax.annotation</groupId> <artifactId>javax.annotation-api</artifactId></dependency><dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId></dependency><dependency> <groupId>com.sun.xml.bind</groupId> <artifactId>jaxb-core</artifactId></dependency><dependency> <groupId>com.sun.xml.bind</groupId> <artifactId>jaxb-impl</artifactId></dependency>maven相干依赖版本升级<!-- 仅供参考 --><maven-compiler-plugin.version>3.8.1</maven-compiler-plugin.version><maven-assembly-plugin.version>3.3.0</maven-assembly-plugin.version><maven-resources-plugin.version>3.2.0</maven-resources-plugin.version><maven-jar-plugin.version>3.2.0</maven-jar-plugin.version><maven-surefire-plugin.version>3.0.0-M5</maven-surefire-plugin.version><maven-deploy-plugin.version>3.0.0-M1</maven-deploy-plugin.version><maven-release-plugin.version>3.0.0-M1</maven-release-plugin.version><maven-site-plugin.version>3.9.1</maven-site-plugin.version><maven-enforcer-plugin.version>3.0.0-M2</maven-enforcer-plugin.version><maven-project-info-reports-plugin.version>3.1.0</maven-project-info-reports-plugin.version><maven-plugin-plugin.version>3.6.1</maven-plugin-plugin.version><maven-javadoc-plugin.version>3.3.0</maven-javadoc-plugin.version><maven-source-plugin.version>3.2.1</maven-source-plugin.version><maven-jxr-plugin.version>3.0.0</maven-jxr-plugin.version>Lombok版本升级https://projectlombok.org/changelog<dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <!-- <version>1.16.20</version>--> <version>1.18.22</version></dependency> ...

作者：京东科技 韩国凯 一、问题发现与排查1.1 找到问题起因问题起因是咱们收到了jdos的容器CPU告警，CPU使用率曾经达到104% 察看该机器日志发现，此时有很多线程在执行跑批工作。失常来说，跑批工作是低CPU高内存型，所以此时思考是FullGC引起的大量CPU占用（之前有相似状况，告知用户后重启利用后解决问题）。 通过泰山查看该机器内存应用状况： 能够看到CPU的确使用率偏高，然而内存使用率并不高，只有62%，属于失常范畴内。 到这里其实就有点蛊惑了，按情理来说此时内存应该曾经打满才对。 前面依据其余指标，例如流量的忽然进入也狐疑过是jsf接口被忽然大量调用导致的cpu占满，所以内存使用率不高，不过前面都缓缓排除了。其实在这里就有点束手无策了，景象与猜想不符，只有CPU增长而没有内存增长，那么什么起因会导致单方面CPU增长？而后又朝这个方向排查了半天也都被否定了。 前面忽然意识到，会不会是监控有“问题”？ 换句话说应该是咱们看到的监控有问题，这里的监控是机器的监控，而不是JVM的监控！ JVM的应用的CPU是在机器上能体现进去的，而JVM的堆内存高额应用之后在机器上体现的并不是很显著。 遂去sgm查看对应节点的jvm相干状况： 能够看到咱们的堆内存老年代的确有过被打满而后又清理后的状况，查看此时的CPU应用状况也能够与GC工夫对应上。 那么此时能够确定，是Full GC引起的问题。 1.2 找到FULL GC的起因咱们首先dump出了gc前后的堆内存快照， 而后应用JPofiler进行内存剖析。（JProfiler是一款堆内存剖析工具，能够间接连接线上jvm实时查看相干信息，也能够剖析dump进去的堆内存快照，对某一时刻的堆内存状况进行剖析） 首先将咱们dump进去的文件解压，批改后缀名.bin，而后关上即可。（咱们应用行云上自带的dump小工具，也能够本人去机器上通过命令手工dump文件） 首先抉择Biggest Objects，查看过后堆内存中最大的几个对象。 从图中能够看出，四个List对象就占据了近900MB的内存，而咱们刚刚看到堆内存最大也只有1.3GB，因而再加上其余的对象，很容易就会把老年代占满引发full gc的问题。 抉择其中一个最大的对象作为咱们要查看的对象 这个时候咱们曾经能够定位到对应的大内存对象对应的地位： 其实至此咱们曾经可能大略定位出问题所在，如果还是不确定的话，能够查看具体的对象信息，办法如下： 能够看到咱们的大List对象，其实外部是很多个Map对象，而每个Map对象中又有很多键值对。 在这里也能够看到Map中的相干属性信息。 也能够在以下界面间接看到相干信息： 而后一路点上来就能够看到对应的属性。 至此，咱们实践上曾经找到了大对象在代码中的地位。 二、问题解决2.1 找到大对象在代码中的地位与问题的根本原因首先咱们根据上述过程找到对应地位与逻辑 咱们的我的项目中大略逻辑是这样的： 首先会解析用户上传的Excel样本，并将其加载到内存中作为一个List变量，即咱们上述看到的变量。一个20w的样本，此时字段数量有a个，大略占用空间100mb左右。而后遍历循环用户样本，依据用户样本中的数据，再减少一些额定的申请数据，依据此数据申请相干后果。此时字段数量有a+n个，占用空间曾经在200mb左右。循环实现后将此200mb的数据存入缓存。开始生成excel，将200mb数据从缓存中取出，并依据之前记录的a个字段，取出初始的样本字段填充至excel。用流程图示意为： 联合一些具体排查问题的图片： 其中一个景象是每次gc后的最小内存正在逐渐变大，对应上述步骤中第二步，内存正在逐渐收缩。 论断： 将用户上传的excel样本加载到内存中，并将其作为一个List<Map<String, String>>的构造存储起来，首先一个20mb的excel文件以此形式存储会收缩占用120mb左右堆内存，此步骤会大量占用堆内存，并且因为工作逻辑起因，该大对象内存会在jvm中存在长达4-12小时之久，导致一但工作过多，jvm堆内存很容易被打满。 这里列举了为什么应用HashMap会导致内存收缩，其次要起因是存储空间效率比拟低： 一个Long对象占内存计算：在HashMap<Long，Long>构造中，只有Key和Value所寄存的两个长整型数据是无效数据，共16字节（2×8字节）。这两个长整型数据包装成java.lang.Long对象之后，就别离具备8字节的MarkWord、8字节的Klass指针，再加8字节存储数据的long值（一个包装对象占24字节）。 而后这2个Long对象组成Map.Entry之后，又多了16字节的对象头（8字节MarkWord+8字节Klass指针=16字节），而后一个8字节的next字段和4字节的int型的hash字段（8字节next指针+4字节hash字段+4字节填充=16字节），为了对齐，还必须增加4字节的空白填充，最初还有HashMap中对这个Entry的8字节的援用，这样减少两个长整型数字，理论消耗的内存为(Long(24byte)×2)+Entry(32byte)+HashMapRef(8byte)=88byte，空间效率为无效数据除以全副内存空间，即16字节/88字节=18%。 ——《深刻了解Java虚拟机》5.2.6 以下是刚上传的excel中dump出的堆内存对象，其占用的内存达到了128mb，而上传的excel理论只有17.11mb。 空间效率17.1mb/128mb≈13.4% 2.2 如何解决此问题暂且不探讨上述流程是否正当，解决办法个别能够分为两类，一类是治标，即不把该对象放入jvm内存中，转而存入缓存中，不在内存中则大对象问题天然迎刃而解。另一类是治本，即放大该大内存对象，在日常应用场景下使其个别不会触发频繁的full gc问题。 两种形式各有优劣： 2.2.1 激进医治：不把他存入内存解决逻辑也很简略，例如在加载数据时，将其依照样本加载数据一条一条存入redis缓存，而后咱们只须要晓得样本中有多少的数量，依照数量的先后顺序从缓存中取出数据，即可解决该问题。 长处：能够从根本上解决此问题，当前基本上不会存在该问题，数据量再大只须要增加相应的redis资源即可。 毛病：首先会减少许多redis缓存空间耗费，其次从显示思考对于咱们我的项目来说，此处代码古老且艰涩难懂，改变须要较大工作量与回归测试。 ...

引言本文记录一次线上 GC 问题的排查过程与思路，心愿对各位读者有所帮忙。过程中也走了一些弯路，当初有工夫积淀下来思考并总结进去分享给大家，心愿对大家今后排查线上 GC 问题有帮忙。 背景服务新性能发版一周后下午，忽然收到 CMS GC 告警，导致单台节点被拉出，随后集群内每个节点先后都产生了一次 CMS GC，拉出后的节点垃圾回收后接入流量恢复正常（预先排查发现被重启了）。 告警信息如下（已脱敏）： 多个节点简直同时产生 GC 问题，且排查天然流量监控后发现并未有显著增高，根本能够确定是有 GC 问题的，须要解决。 排查过程GC 日志排查GC 问题首先排查的应该是 GC 日志，日志能可能清晰的断定产生 GC 的那一刻是什么导致的 GC，通过剖析 GC 日志，可能清晰的得出 GC 哪一部分在出问题，如下是 GC 日志示例： 0.514: [GC (Allocation Failure) [PSYoungGen: 4445K->1386K(28672K)] 168285K->165234K(200704K), 0.0036830 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]0.518: [Full GC (Ergonomics) [PSYoungGen: 1386K->0K(28672K)] [ParOldGen: 163848K->165101K(172032K)] 165234K->165101K(200704K), [Metaspace: 3509K->3509K(1056768K)], 0.0103061 secs] [Times: user=0.05 sys=0.00, real=0.01 secs]0.528: [GC (Allocation Failure) [PSYoungGen: 0K->0K(28672K)] 165101K->165101K(200704K), 0.0019968 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]0.530: [Full GC (Allocation Failure) [PSYoungGen: 0K->0K(28672K)] [ParOldGen: 165101K->165082K(172032K)] 165101K->165082K(200704K), [Metaspace: 3509K->3509K(1056768K)], 0.0108352 secs] [Times: user=0.03 sys=0.00, real=0.01 secs]如上 GC 日志能很显著发现导致 Full GC 的问题是：Full GC 之后，新生代内存没有变动，老年代内存应用从 165101K 升高到 165082K （简直没有变动）。这个程序最初内存溢出了，因为没有可用的堆内存创立 70m 的大对象。 ...

原创：扣钉日记（微信公众号ID：codelogs），欢送分享，转载请保留出处。简介最近，咱们系统配置了GC耗时的监控，但配置上之后，零碎会偶然呈现GC耗时大于1s的报警，排查花了一些力量，故在这里分享下。 发现问题咱们零碎分多个环境部署，呈现GC长耗时的是俄罗斯环境，其它环境没有这个问题，这里比拟奇怪的是，俄罗斯环境是流量最低的一个环境，而且大多数GC长耗时产生在深夜。 发现报警后，我立马查看了GC日志，如下：  日志中呈现了to-space exhausted，通过一番理解，呈现这个是因为g1在做gc时，都是先复制存活对象，再回收原region，当没有闲暇空间复制存活对象时，就会呈现to-space exhausted，而这种GC场景代价是十分大的。 同时，在这个gc产生之前，还发现了一些如下的日志。 这里能够看到，零碎在调配约30M+的大对象，难道是有代码频繁调配大对象导致的gc问题。 定位大对象产生地位jdk在调配大对象时，会调用G1CollectedHeap::humongous_obj_allocate办法，而应用async-profiler能够很容易晓得哪里调用了这个办法，如下： # 开启收集./profiler.sh start --all-user -e G1CollectedHeap::humongous_obj_allocate -f ./humongous.jfr jps# 进行收集./profiler.sh stop -f ./humongous.jfr jps将humongous.jfr文件用jmc关上，如下： 依据调用栈我发现，这是咱们的一个定时工作，它会定时调用一个接口获取配置信息并缓存它，而这个接口返回的数据量达14M之多。 难道是这个接口导致的gc问题？但这个定时工作调用也不频繁呀，5分钟才调用一次，不至于让gc忙不过来吧！ 另一个疑难是，这个定时工作在其它环境也会运行，而且其它环境的业务流量大得多，为什么其它环境没有问题？ 至此，我也不确定是这个定时工作导致的问题，还是零碎本身特点导致偶然的高gc耗时。 因为咱们有固定的上线日，于是我打算先优化产生大对象的代码，而后在上线前的期间试着优化一下jvm gc参数。 优化产生大对象的代码咱们应用的是httpclient调用接口，调用接口时，代码会先将接口返回数据读取成String，而后再应用jackson把String转成map对象，简化如下： rsp = httpClient.execute(request);String result = IOUtils.toString(rsp.getEntity().getContent());Map resultMap = JSONUtil.getMapper().readValue(result, Map.class);要优化它也很简略，应用jackson的readValue有一个传入InputStream的重载办法，用它来读取json数据，而不是将其加载成一个大的String对象再读，如下： rsp = httpClient.execute(request);InputStream is = rsp.getEntity().getContent();Map resultMap = JSONUtil.getMapper().readValue(is, Map.class);注：这外面map从逻辑上来说是一个大对象，但对jvm来说，它只是很多个小对象而后用指针连接起来而已，大对象个别由大数组造成，大String之所以是大对象，是因为它外面有一个很大的char[]数组。优化GC参数优化完代码后，我开始钻研优化jvm gc参数了，咱们应用的是jdk8，垃圾收集器是g1，为了了解g1的调优参数，又简略学习了下g1的要害概念。 g1是分region收集的，但region也分年老代与老年代。g1的gc分young gc与mixed gc，young gc用于收集年老代region，mixed gc会收集年老代与老年代region。在mixed gc回收之前，须要先经验一个并发周期(Concurrent Cycles)，用来标记各region的对象存活状况，让mixed gc能够判断出须要回收哪些region。并发周期分为如下4个子阶段： a. 初始标记(initial marking) b. 并发标记(concurrent marking) c. 从新标记(remarking) d. 清理(clean up) 须要留神的是，初始标记(initial marking)这一步是借助young gc实现的。在g1中，young gc简直没有什么可调参数，而mixed gc有一些，常见如下： ...

序言本指南文档通过向纯熟的 Go 用户提供对于 Go GC 一些深刻信息，来帮忙他们更好的对本人程序的运行代价的了解。同时也给 Go 用户提供一份如何深刻洞察优化程序资源利用率的指南。本指南并不假如你相熟 GC，然而对 Go 语言的熟知是必须的。 Go 语言负责管理所有的语言的值(values)，绝大多数状况下，Go 开发者并不需要关注这些值是如何被存储。当然，这些数据实际上是存储在无限的物理内存中的。 因为内存的限度，因而它必须被审慎的治理，和被回收重用，防止被一个运行的程序耗尽。依据需要调配和回收内存，是 Go 语言负责的工作。 主动回收利用内存被称为垃圾回收(garbage collection)。垃圾回收（简称 GC） 是一个回收被判断为程序不会再应用的内存的零碎。Go 语言提供一个运行时库(runtime library)，它随同每个 Go 程序一起执行，提供了 GC 性能。 请留神，在 Go 语言标准中并没有确保存在 GC，标准只提到了底层存储的值是由语言本人治理的。（语言标准中的）这项规范是成心脱漏的，它容许理论的（Go 语言实现）应用齐全不同的内存治理技术。 尽管如此，本指南形容的只是 Go 语言的一个特定实现，可能不适用于其余的实现。再具体一点，本指南只针对 Go 语言官网规范工具链 的实现。在 Gccgo 和 Gollvm 这两个实现中 GC 和（规范工具链）十分类似，有大量雷同的概念，然而实现细节可能不一样。 另外，本文档更新以实用与最新的 Go 版本。目前，本文档形容的是 Go 1.19 的 GC。 Go 的值(Values) 存在于哪里在咱们深刻探讨 GC 之前，先讨论一下那些不须要被 GC 治理的内存。比方，被存储在 local 变量的非指针值很有可能齐全不须要被 Go GC 治理，而是被调配在它具备雷同的词法作用域的内存中。通常这样会比应用 GC 更加高效，因为 Go 编译器可能事后计算出这块内存什么时候被回收，并且收回清理的指令。 咱们称这一类调配为栈调配，因为他的空间正是存在于在执行代码的 goroutine 堆栈上。 ...

1. 获取pidps -aux | grep java2. 查看堆中对象统计jmap -histo [pid]3. jmapjmap -heap [pid]4. dump剖析jmap -dump:format=b,file=./j.dump [pid]jhat -J-Xmx1024M ./j.dump

残缺高频题库仓库地址：https://github.com/hzfe/aweso... 残缺高频题库浏览地址：https://febook.hzfe.org/ 相干问题什么是内存透露常见的垃圾回收算法如何排查内存透露答复关键点援用计数法 标记革除法 Mark-Compact（标记整顿） Scavenger（清道夫） GC（Garbage Collection，垃圾回收）是一种内存主动管理机制， 垃圾回收器（Garbage Collector）能够主动回收调配给程序的曾经不再应用的内存。常见的 GC 算法有援用计数法和标记革除法等。V8（JavaScript 引擎，提供执行 JavaScript 的运行时环境）的垃圾回收器算法次要由 Mark-Compact 和 Scavenger 形成。 知识点深刻1. 内存透露内存透露是指，该当被回收的对象没有被失常回收，变成常驻老生代的对象，导致内存占用越来越高。内存透露会导致应用程序速度变慢、高延时、解体等问题。 1.1 内存生命周期调配：按需分配内存。应用：读写已调配的内存。开释：开释不再须要的内存。1.2 内存透露常见起因创立全局变量，且没有手动回收。事件监听器 / 定时器 / 闭包等未失常清理。应用 JavaScript 对象来做缓存，且不设置过期策略和对象大小管制。队列拥塞所带来的生产不及时问题。2. Reference Counting（援用计数）Reference Counting 是常见的垃圾回收算法，其外围思路是：将资源（比方对象）的被援用次数保存起来，当被援用次数为零时开释。该办法的局限性：当呈现循环援用时，相互援用的对象不会被回收。 3. V8 垃圾回收机制V8 中有两个垃圾收集器。次要的 GC 应用 Mark-Compact 垃圾回收算法，从整个堆中收集垃圾。小型 GC 应用 Scavenger 垃圾回收算法，收集新生代垃圾。 两种不同的算法应答不同的场景： 应用 Scavenger 算法次要解决存活周期短的对象中的可拜访对象。应用 Mark-Compact 算法次要解决存活周期长的对象中的不可拜访的对象。因为新生代中存活的可拜访对象占多数，老生代中的不可拜访对象占多数，所以这两种回收算法配合应用非常高效。 3.1 分代垃圾收集在 V8 中，所有的 JavaScript 对象都通过堆来调配。V8 将其治理的堆分成两代：新生代和老生代。其中新生代又可细分为两个子代（Nursery、Intermediate）。 即新生代中的对象为存活工夫较短的对象，老生代中的对象为存活工夫较长或常驻内存的对象。 3.2 Mark-Compact 算法（Major GC）Mark-Compact 算法能够看作是 Mark-Sweep（标记革除）算法和 Cheney 复制算法的联合。该算法次要分为三个阶段：标记、革除、整顿。 ...

内存抖动内存抖动是因为大量的对象被创立又在短时间内马上被开释，如循环中调配对象，很容易引起GC，特地是在较大的循环次数或者一个循环中调配较多的长期对象时。 霎时产生大量的对象霎时产生大量的对象，即便对象不大，也可能使得堆的可用空间达到阈值登程GC或导致堆的扩容产生GC。 调配大内存块的对象调配大内存块的对象，如图片，大的byte数组等，尽管堆残余内存空间足够，然而依然可能登程GC，因为内存碎片导致了找不到间断空间来调配这大内存，从而登程GC。 内存泄露内存泄露，会导致可用内存越来越少，而且导致碎片也可能越来越重大，这样就更加容易登程GC。

工作原理在面向对象编程中，每个类型都代表一种可供程序应用的资源。要应用这些资源必须为代表资源的类型分配内存。拜访一个资源所须要的步骤如下： 调用IL指令newobj，为代表资源的类型分配内存。在C#中应用new关键字，编译器会主动生成该指令初始化内存，设置资源的初始状态，使资源可用。类型的实例结构器负责初始状态拜访类型的成员来应用资源捣毁资源的状态以进行清理开释内存，由垃圾回收负责这看似简略的步骤，却频频引发编程谬误，如应用了已被开释的内存和没有开释不再须要的内存。 在非托管编程中，这种bug会造成内存透露(节约内存)和对象损坏的问题，如何正确的进行内存治理便是一个很重要的问题，而垃圾回收便是专门负责这一性能的。 从托管堆分配内存CLR要求所有资源都从托管堆调配，对象在应用程序不须要应用时便会被主动删除。 过程初始化时，CLR要保留一块间断的、最后并没有对应的物理存储空间地址空间，这个地址空间就是托管堆。托管堆保护着一个指向下一个对象在堆中调配的地位的指针NextObjPtr。刚开始的时候NextObjPtr设置为保留地址空间的基地址。 IL指令newobj用于创立一个对象，该指令会让CLR执行以下步骤： 计算类型以及所有基类型的字段须要的字节数加上对象开销所须要的字节数，每个对象都具备的两个开销字段：类型对象指针和一个同步索引块。对于32位应用程序两个字段各占32位须要8字节，64位应用程序两个字段各占64位须要16字节CLR查看保留区域是否可能提供调配对象所需的字节数，如果有必要就提交存储。如果托管堆有足够的空间，对象会被放入，对象将会放在NextObjPtr指针指向的地址中，并且为它调配的字节将会被清零。接着调用类型的实例结构器位this参数传递NextObjPtr，newobj指令将返回对象的地址。在地址返回前，NextObjPtr指针的值会加上对象占据的字节数从而失去一个新值，它指向下一个对象放入托管堆的地址 垃圾回收器工作原理应用程序调用new操作符创建对象时，可能存在没有足够的内存空间来调配该对象的状况，托管堆将对象须要的字节数加到NextObjPtr指针中的地址上来检测这种状况，如果后果值超过了地址空间的开端，表明托管堆已满，此时必须执行一次垃圾回收。 垃圾回收算法垃圾回收器查看应用程序中是否存在不再应用的对象，如果存在，它们应用的内存就能够回收，如果一次垃圾回收之后，堆中任然没有可用的内存，new操作符将会抛出一个OutOfMemoryException异样。 应用程序的root每个应用程序都蕴含一组根，每个根都是一个存储地位，其中蕴含一个指向援用类型对象的一个指针。该指针要么援用托管堆中的一个对象，要么为null *只有援用类型的变量才被认为是根，值类型的变量永远不认为是根 垃圾回收器如何晓得应用程序正在应用一个对象？标记阶段：垃圾回收器在开始执行时，总是假如堆中所有的对象都是垃圾。垃圾回收器沿着线程栈上行查看所有的根，如果发现一个根援用了一个对象，就在对象的同步索引字段上设置一个bit。例如应用程序的根间接援用了A，B，C对象，所有这些对象都被标记。在标记对象C的时候发现对象C援用了对象D的一个字段，造成对象D也被标记。垃圾回收器就是这样以递归的形式遍历所有可达对象。标记好根和它的援用对象后，垃圾回收器查看下一个根，并持续标记对象，如果试图标记一个先前曾经标记过的对象，就会沿着这个门路走上来，不会进行二次遍历查看好所有根之后，堆中将蕴含一组已标记和未标记的对象。已标记的对象是通过利用程序代码可达的对象，而未标记的对象是不可达的认为是垃圾，它们占用的内存能够回收。垃圾回收器将进入压缩阶段压缩阶段：垃圾回收器线性地遍历堆，寻找未标记对象的间断内存块，如果发现的内存块较小，垃圾回收器就将其疏忽。然而如果发现大的可间断的内存块，垃圾回收器就会把非垃圾对象挪动到这里以压缩堆。挪动内存中的对象之后，蕴含指向这些对象的指针的变量和CPU寄宿器都将有效。垃圾回收器必须从新拜访应用程序的所有根，并批改它们使其指向对象的新的内存地位。如果对象中的字段指向的是一个曾经挪动了地位的对象，垃圾回收器也要负责改过这些字段。堆内存压缩之后，NextObjPtr指针指向紧接着最初一个非垃圾对象之后的地位*由此可见，垃圾回收将造成显著的性能损失 应用终结操作开释本地资源大多数类型只须要内存便可失常工作，然而还有一些类型除了要应用类型还要应用本地资源，如FileStream类型。终结是CLR提供的一种机制，容许对象在垃圾回收器回收其内存之前执行一些清理操作。这些类型都实现了一个Finalize办法，当垃圾回收器断定一个对象是垃圾时，会调用对象的Finalize办法。 Finalize办法的定义 class People{ //这是一个Finalize办法 ~People() { //这里的代码会进入Finalize办法 }}通过ildasm检查程序集可确认Finalize办法已生成 CriticalFinalizerObject类型首次结构任何CriticalFinalizerObject派生类型的一个对象时，CLR立刻对继承层次结构中的所有Finalize办法进行JIT编译，在结构对象就编译这些办法可确保对象被断定为垃圾的时候本地资源能保障失去开释CLR会先调用非CriticalFinalizerObject派生类性的Finalize办法，再调用CriticalFinalizerObject派生类型的Finalize办法。如此托管类资源便能够在它们的Finalize办法中胜利的拜访CriticalFinalizerObject派生类型的对象如果AppDomain被一个宿主应用程序强行中断，CLR也会调用CriticalFinalizerObject派生类型的Finalize办法。宿主应用程序不再信赖它外部运行的托管代码时也利用这个性能确保本地资源得以开释引起Finalize办法调用的起因第0代满时，会主动触发垃圾回收，导致Finalize办法被调用的最常见的起因代码显示调用System.GC的静态方法Collect，不倡议这样操作Windows提醒内存不足CLR卸载AppDomain，卸载时CLR会认为AppDomain中不再存在任何根，因而会对所有代的对象执行垃圾回收CLR敞开，一个过程失常终止时，CLR就会敞开。在敞开过程中，CLR会认为该过程中不再存在任何根，因而会调用托管堆中的所有对象的Finalize办法。此时因为整个过程都要终止，CLR不会尝试压缩或开释内存，将有Windows负责回收过程的所有内存应用Finalize办法造成的性能影响可终结的对象要花更长的工夫分配内存，因为指向它们的指针必须放到终结列表中可终结对象在回收时必须进行一些额定的解决，导致程序的运行速度变慢Finalize办法揭秘应用程序创立新对象时，new操作符会从堆中分配内存，如果对象定义了Finalize办法，那么在该类的实例结构器被调用之前，会将指向该对象的一个指针放到一个终结列表。终结列表是由垃圾回收器管制的一个外部数据结构，列表中的每一项都指向一个对象。在回收该对象之前应该调用它的Finalize办法。 *结构一个类型的实例时，如果该类型的Finalize办法是从Object继承的，就不认为这个对象是能够终结的。类型必须重写Object的Finalize办法，这个类型及其派生类的对象才被人为是能够终结的。 垃圾回收器开始时，会查找终结列表中指向垃圾对象的指针。找到一个指针后，该指针会从终结列表中移除，并追加到垃圾回收器的另一个外部数据结构freachable队列中，freachable队列中的每个指针都代表其Finalize办法曾经筹备好的一个对象。 一个非凡的高优先级CLR线程专门负责Finalize办法的调用，当freachable队列为空时，这个线程将会休眠。一旦队列不为空，该线程便会被唤醒，将每一项从freachable队列中移除，并调用每个对象的Finalize办法。 freachable队列垃圾回收器会将不可达的对象视为垃圾，然而，当垃圾回收器将对象的援用从终结列表挪动到freachable队列后，对象将不再被认为是垃圾，其内存不可被回收。标记freachable对象时，这些对象的援用类型的字段所援用的对象也会被递归标记。所有这些对象都会在垃圾回收的过程中存活下来。这时，垃圾回收器完结对垃圾的标识(这个过程中会有某一些被认为是垃圾的对象又被从新认为不是垃圾)。而后垃圾回收器开始压缩可回收内存，非凡的CLR线程清空freachable队列，并执行每个对象的Finalize办法。垃圾回收器下一次调用时，会发现已终结的对象成为真正的垃圾，因为应用程序的根不再指向它，freachable队列也不再指向它。所以这些对象的内存会间接回收。*整个过程中，可终结的对象须要执行两次垃圾回收能力开释它们占用的内存。 FInalize办法蕴含共享状态的代码应该应用线程同步锁，在只有一个终结线程的状况下，可能存在多个CPU调配可终结的对象，但只有一个线程执行Finalize办法，会造成该线程可能跟不上调配速度，造成性能和伸缩性方面的问题。 using语句static void Main(){ using (FileStream fs = new FileStream("Temp.txt", FileMode.Create)) { fs.Write(new byte[] { 1, 2, 3 }, 0, 3); } File.Delete("Temp.txt");}应用using语句的时候编译器会主动生成一个try块和一个Finally块。显然，在Finally块中，编译器会生成代码将变量转型成一个IDisposable并调用Dispose办法。所以using语句只能用于实现了IDisposable接口的类型。 手动监督和管制对象的生存期GC Handle tableCLR为每个AppDomain都提供了一个GC句柄表，该表容许程序监督对象的生存期，或手动管制对象的生存期。在一个AppDomain创立之初，句柄表是空的。句柄表的每个记录项都蕴含两种信息：一个指向托管堆上一个对象的指针；一个flag标记，它指出想要监督或管制的对象。 应用GCHandle的Alloc办法管制或监督对象的生存期 public static GCHandle Alloc(object value, GCHandleType type);GCHandleType枚举 Weak：容许监督对象的生存期。可检测垃圾回收在什么时候断定该对象在利用程序代码中行将不可达。此时对象的Finalize可能曾经执行也可能没有执行，对象可能依然存在内存中。WeakTrackResurrection：容许监督对象的生存期。可检测垃圾回收在什么时候断定该对象在利用程序代码中行将不可达。此时对象的Finalize曾经执行，对象的内存已回收。Normal：容许管制对象的生存期。通知垃圾回收器：行将应用应用程序中没有变量援用的对象，该对象必须保留在内存中。垃圾回收产生时，该对象的内存能够压缩(挪动)。如果不向Alloc传递任何GCHandleType标记，就默认应用GCHandleType.Normal标记。Pinned：容许管制对象的生存期。通知垃圾回收器：行将应用应用程序中没有变量援用的对象，该对象必须保留在内存中。垃圾回收产生时，该对象的内存不能压缩(挪动)。须要将内存地址传给非托管代码时，这个标记就十分有用。非托管代码能够释怀的向托管代码的这个内存写入，晓得托管对象的地位不会因为垃圾回收而挪动。调用Alloc办法时，扫描AppDomain的GC句柄表，查找一个可用的记录项来存储传给Alloc的对象地址，并将标记设置为GCHandleType实参传递的值。接着返回GCHandle实例，该实例是一个轻量级的值类型，其中蕴含一个实例字段，它援用了句柄表中的记录索引项。能够通过获取GCHandle实例，调用其Free办法开释GC句柄表中的记录项，使GCHandle实例有效。 垃圾回收器如何应用GC句柄表垃圾回收器标记所有可达对象，而后扫描GC句柄表。所有Normal和Pinned都被看成时根，同时标记这些对象(包含这些对象的字段援用的对象)垃圾回收器扫描GC句柄表，查找所有Weak记录项。如果一个Weak记录项援用了一个未标记的对象，指针标识的就是一个垃圾对象，记录项的指针更改为null垃圾回收器扫描中结列表，如果列表中的一个指针未援用标记的对象，指针标识的就是一个不可达对象，指针将从终结列表移入freachable队列。这时对象将会被标记，因为对象又变成了可达对象垃圾回收器扫描GC句柄表，查找所有WeakTrackResurrection记录项。如果一个WeakTrackResurrection记录项援用了一个未标记的对象(由freachable队列中的一个记录项指向的一个对象)，指针标识的就是一个垃圾对象，该记录项的指针值更改为null垃圾回收器对内存进行压缩，其实就是内存碎片整顿的过程。某些状况下如果垃圾回收器判断内存碎片化不重大，就会决定不压缩内存。Pinned对象是不会压缩(挪动)的，所以垃圾回收器会将其它对象移到它的四周托管代码的援用传给非托管代码要应用Pinned标记，因为非托管代码要回调托管代码时，不能真正的将指向一个托管对象的指针传给非托管代码，因为如果产生垃圾回收，对象可能在内存中挪动，指针便有效了。为了失常工作，调用Alloc办法，向它传递对象援用和Pinned标记，而后将返回的GCHandle实例转型成为一个Intptr，再将Intptr传递给非托管代码。非托管代码回调托管代码时，托管代码将Intptr转型成为GCHandle，查问Target属性取得托管对象的援用，非托管代码不再须要这个援用后能够调用GCHandle实例的Free办法，使将来的垃圾回收能开释这些对象。 对象复活一个被视为垃圾的对象又从新被当做可达(非垃圾)对象的过程，成为对象复活。垃圾回收器将一个对象的援用放入freachable队列，对象就变成可达对象了。待对象的Finalize办法返回，不再有根指向对象，对象才真正死亡。 Finalize办法在执行时将对象指针放到一个动态字段中 class Program{ public static Object s_Obj = null;}class SomeType{ ~SomeType() { Program.s_Obj = this; }}上述代码展现了当SomeType的Finalize办法被调用时，该对象的援用会被放入到一个根，使对象得以复活，应用程序能够自在应用这个对象。但须要留神的是，这个对象已经被终结，所以应用它可能造成无奈预测的后果。如果SomeType的一些字段援用了其它对象，这些对象都会被复活，在这些对象中一部分对象的Finalize办法曾经被调用过了。 ...

目录GC相干概念常见GC算法援用计数算法 核心思想实现原理实例优缺点标记革除算法 核心思想实现原理图示优缺点标记整顿算法 核心思想实现原理图示优缺点GC相干概念[x] GC：垃圾回收机制的简写，垃圾回收期实现具体的工作.能够找到内存中的垃圾、并开释和回收空间[x] GC垃圾：程序中 不再须要应用的，程序中不能再拜访的 对象[x] GC算法：是GC工作时查找和回收所遵循的规定常见GC算法援用计数标记革除标记整顿分待回收（V8用到的）援用计数算法核心思想设置援用数，判断以后援用数是否为0来决定是不是垃圾对象，如果是0就GC就进行工作，进行回收。 实现原理援用计数器援用关系扭转时批改援用数字援用数字为0时立刻回收实例const user1 = { age: 11 }const user2 = { age: 12 }const user3 = { age: 13 }const nameList = [user1.age, user2.age, user3.age]function fn() { const num1 = 1 const num2 = 2 num3 = 3}fn()当函数调用过后，num1和num2在内部不能应用，援用数为0，会被回收 ; num3是挂载在window上的，所以不会被回收 ; 下面的user1、user2、user3被nameList援用，所以援用数不为0不会被回收 ;优缺点援用计数算法内容长处1. 发现垃圾时立刻回收<br/>2. 最大限度缩小程序暂停，让空间不会有被占满的时候毛病1. 无奈回收循环援用的对象<br/>2. 资源耗费开销大（对所有对象进行数值的监控和批改，自身就会占用工夫和资源）上面举一栗子阐明下面毛病中无奈回收循环利用对象的状况： function fn() { const obj1 = {} const obj2 = {} obj1.name = obj2 obj2.name = obj1 return 'hello world'}fn()// obj1和obj2，因为相互有援用，所以计数器并不为0，fn调用之后仍旧无奈回收这两个对象标记革除算法相比原理实现更加简略，还能解决相应问题，V8当中会大量应用到。 ...

关注“Java后端技术全栈” 回复“000”获取大量电子书 在工作中，当一个零碎产生OOM的时候，这种问题可能会让大家很懊恼困惑，因为故障排查起来是一个综合技术的考量。在平时工作中要减少本人的常识广度，多学习，多总结，多思考，多做笔记，这才是真正的王道。 尤其是在线上环境中，如何剖析是哪个线程导致的CPU飙高的问题，通常大抵有几个差不多固定的步骤。这个问题也是面试频率十分之高的问题之一，很多人也是靠答复这个问题而加薪。 常见套路步骤： 应用top命令应用top -H pid 应用prinf %x tid 应用jsack pid >pid.log 查阅less pid.log 上面就来说一下这几个步骤。 top咱们能够应用top命令来查找对应应用CPU最多的过程，找到后，先记录下对应的pid（前面要用到）。 再应用Shift+P这两个快捷键能够按CPU的使用率进行排序。 top-H pid再次应用top名，然而这次减少一个参数-H，能够查看下面找进去的pid过程中对应的线程tid，记住这时候的线程tid得记住 printf然而此时的tid是十进制的，咱们须要把这个tid转成16进制。而后应用 printf %x tid stack应用jstack工具把线程信息输入到对应的日志文件中，前面应用这个日志文件内容进行剖析。 jstack pid >pid.log less下面曾经生成日志文件了，这时候能够应用less命令来查找下面曾经转换好的16进制的线程tid。 less pid.log 其它另外还能够应用 jstat -gcutil pid 1000 10 来查看垃圾回收的实时状况。 对于jstat的应用前参考后面的文章 工具。 举荐一篇很全的线上CPU飙高的解决文章 http://woaijava.cc/blog/20111... 举荐浏览： 《Spring Cloud与Docker微服务架构实战》.pdf 《Go语言实战》.pdf 《分布式Java利用根底与实际》.pdf

JVM介绍1. JVM的体系架构（内存模型） 绿色的为线程公有，橘色的为线程共有 2. 类加载器负责将.class文件加载到内存中，并且将该文件中的数据结构转换为办法区中的数据结构，生成一个Class对象 2.1 类加载器分类自启动类加载器。Bootstrap ClassLoader类加载器。负责加载jdk自带的包。 %JAVA_HOME%/lib/rt.jar%即JDK源码应用C++编写在程序中间接获取被该加载器加载的类的类加载器会呈现null扩大类加载器.Extension ClassLoader。负责加载jdk扩大的包 便于将来扩大%JAVA_HOME/lib/ext/*.jar%利用类加载器或零碎类加载器。AppClassLoader或SystemClassLOader 用于加载自定义类的加载器CLASSPATH门路下自定义类加载器 通过实现ClassLoader抽象类实现2.2 双亲委派机制当利用类加载器获取到一个类加载的申请的时候，不会立刻解决这个类加载申请，而是将这个申请委派给他的父加载器加载，如果这个父加载器不可能解决这个类加载申请，便将之传递给子加载器。一级一级传递领导能够加载该类的类加载器。 该机制又称沙盒平安机制。避免开发者对JDK加载做毁坏 2.3 突破双亲委派机制自定义类加载器，重写loadClass办法应用线程上下文类加载器2.4 Java虚拟机的入口文件sun.misc.Launcher类 3. Execution Engine执行引擎负责执行解释命令，交给操作系统进行具体的执行 4. 本地接口4.1 native办法native办法指Java层面不能解决的操作，只能通过本地接口调用本地的函数库(C函数库) 4.2 Native Interface一套调用函数库的接口 5. 本地办法栈在加载native办法的时候，会将执行的C函数库的办法，放在这个栈区域执行 6. 程序计数器每个线程都有程序计数器，次要作用是存储代码指令，就相似于一个执行打算。 外部保护了多个指针，这些指针指向了办法区中的办法字节码。执行引擎从程序计数器中获取下一次要执行的指令。 因为空间很小，他是以后线程执行代码的一个行号指示器/ 不会引发OOM 7. 办法区供各线程共享的运行时内存区域，寄存了各个类的构造信息(一个Class对象)，包含：字段，办法，构造方法，运行时常量池。 尽管JVM标准将办法区形容为堆的一个逻辑局部，但它却还有一个别名叫做Non-Heap(非堆)，目标就是要和堆离开 次要有：永恒代或者元空间。存在GC 元空间中因为间接应用物理内存的影响，所以默认的最大元空间大小为1/4物理内存大小 8. Java栈次要负责执行各种办法，是线程公有的，随线程的沦亡而沦亡，不存在垃圾回收的问题。八大数据类型和实例援用都是在函数的栈内存中分配内存的。 默认大小为512~1024K，通过-Xss1024k参数批改 8.1 栈和队列数据结构栈FILO：先进后出 队列FIFO：先进先出 8.2 存储的数据本地变量Local Variable。包含办法的形参和返回值栈操作Operand Stack。包含各种压栈和出栈操作栈帧数据Frame Data。就相当于一个个办法。在栈空间中，办法被称为栈帧8.3 执行流程栈中执行的单位是栈帧，栈帧就是一个个办法。 首先将main办法压栈，成为一个栈帧而后调用其余办法，即再次压栈栈帧中存储了这个办法的局部变量表，操作数栈、动静链接、办法进口等栈的大小和JVM的实现无关，通常在256K~756K 9. 办法区，栈，堆的关系 10. Heap 堆10.1 堆内存构造默认初始大小为物理内存的1/64，默认最大大小为1/4。在理论生产中个别会将这两个值设置为雷同，防止垃圾回收器执行完垃圾回收当前还须要进行空间的扩容计算，浪费资源。 堆外内存：内存对象调配在Java虚拟机的堆以外的内存，这些内存间接受操作系统治理（而不是虚拟机），这样做的后果就是可能在肯定水平上缩小垃圾回收对应用程序造成的影响。应用未公开的Unsafe和NIO包下ByteBuffer来创立堆外内存。 默认的堆外内存大小为,通过-XX:MaxDirectMemorySize=执行堆外内存的大小 10.1.1 JDK1.7 在逻辑上划分为三个区域： 新生区Young Generation Space。 ...

内存治理内存为什么须要治理 function fn(){ arrlist=[]; arrlist[100000]='lg is a coder';}fn(); 不当的操作会导致堆内存，飙升。

后面在jvm组成构造一文中，说到了GC和一些算法，那么在这篇文章里，就具体说说GC的罕用算法。垃圾回收(Garbage Collection，GC)，就是将垃圾回收，防止过于占用内存空间，导致内存透露，对内存堆中曾经死亡或者长时间没有应用的对象进行革除和回收。既然是垃圾回收，那么如何判断哪些对象是垃圾，须要被回收呢? 如何找到程序里的垃圾(1)援用计数法援用计数法其实就是给每个对象增加一个计数器RC，当有中央援用该对象时计数器加1，当援用生效时计数器减1。通过对象计数器是否为0来判断对象是否可被回收。然而相应的，它无奈解决循环援用的问题。倘若如下：定义一个字符串 String str = new String ("tony");其实这个时候，str援用了字符串"tony"，那么这个字符串援用次数就是1，这时候如果m指向了另一个新的值，例如 m=null，那这个时候"tony"的援用次数就成了0了，也就意味着要被回收了。 public class ReferenceCountingGC { public Object instance; public ReferenceCountingGC(String name) { } public static void testGC(){ ReferenceCountingGC a = new ReferenceCountingGC("objA"); ReferenceCountingGC b = new ReferenceCountingGC("objB"); // a和b相互援用了 a.instance = b; b.instance = a; a = null; b = null; }}从代码中能够看出，a，b这两个对象始终在相互援用，如果采纳援用计数法的话，是永远无奈GC它们的，因为它们的援用计数永远都不会为0，所以说援用计数法是有局限性的，或者说它不属于严格意义上的垃圾收集机制。 (1)可达性剖析算法GC ROOT是什么？ 首先咱们晓得标记算法，JVM的标记算法咱们能够理解为一个可达性算法，所以所有的可达性算法都会有终点，那么这个终点就是GC Root。也就是须要通过GC Root 找出所有活的对象，那么剩下所有的没有标记的对象就是须要回收的对象。通过 GC ROOT的对象作为搜寻起始点，通过援用向下搜寻，所走过的门路称为援用链。通过对象是否有达到援用链的门路来判断对象是否可被回收（可作为GC ROOT的对象：虚拟机栈中援用的对象，办法区中类动态属性援用的对象，办法区中常量援用的对象，本地办法栈中JNI援用的对象）通过可达性算法，胜利解决了援用计数所无奈解决的循环依赖问题，只有你无奈与GC Root建设间接或间接的连贯，零碎就会断定你为可回收对象。那这样就引申出了另一个问题，哪些属于GC Root。Java内存区域中哪些能够作为GC Root对象？虚拟机栈中援用的对象public class StackLocalParameter { public StackLocalParameter(String name) {} public static void testGC() { StackLocalParameter s = new StackLocalParameter("localParameter"); s = null; }}办法区中类动态属性援用的对象public class MethodAreaStaicProperties { public static MethodAreaStaicProperties m; public MethodAreaStaicProperties(String name) {} public static void testGC(){ MethodAreaStaicProperties s = new MethodAreaStaicProperties("properties"); s.m = new MethodAreaStaicProperties("parameter"); s = null; }}办法区中常量援用的对象public class MethodAreaStaicProperties { public static final MethodAreaStaicProperties m = MethodAreaStaicProperties("final"); public MethodAreaStaicProperties(String name) {} public static void testGC() { MethodAreaStaicProperties s = new MethodAreaStaicProperties("staticProperties"); s = null; }}本地办法栈中援用的对象任何native接口都会应用某种本地办法栈，实现的本地办法接口是应用C连贯模型的话，那么它的本地办法栈就是C栈。当线程调用Java办法时，虚构机会创立一个新的栈帧并压入Java栈。然而当它调用的是本地办法时，虚构机会放弃Java栈不变，不再在线程的Java栈中压入新的帧，虚拟机只是简略地动静连贯并间接调用指定的本地办法。 ...