meser88的博客

新生代初始值（相当于对-XX:newSize、-XX:MaxnewSize同时设置）链接：https://www.jianshu.com/p/60d317d5bd10。商业转载请联系作者获得授权，非商业转载请注明出处。元空间（方法区）扩容阈值（-XX:PermSize jdk7）元空间最大值（-XX:MaxPermSize jdk7）堆内存初始值（建议与 Xmx 设置一样的值,新生代初始值（该值需要小于-Xms的值）新生代最大值（该值需要小于-Xmx的值）查看 java 进程垃圾回收情况。

系统OOM（资源不能被释放）导致服务器频繁且长时间FGC导致服务器CPU持续飚高日志中内存溢出:**java.lang.OutOfMemoryError: Java heap space**程序十分卡顿，严重影响用户使用从以下方面，为大家分享此次问题解决流程问题出现现象临时解决方案复现问题定位问题发生原因优化代码优化后进行压测，上线复盘不同的项目导致内存溢出原因是不同的；重要的是排查思路经过不断的耐心的去观察，测试，分析才能定位到问题并最终解决问题。

JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存，同时对物理内存的使用做了定量的分析，从而实锤了Bug的源头。笔者将此Bug分析的过程写成博客，以飨读者。由于物理内存定量分析部分用到了linux kernel虚拟内存管理的知识，读者如果有兴趣了解请看ulk3(《深入理解linux内核第三版》)查找Bug的时候，现场信息越多越好，同时定位Bug必须要有实质性的证据。例如内存泄露就要用你推测出的模型进行定量分析。

说到线程，我们往往想到的是线程安全、线程池，很少会去考虑线程的内存。那么一个线程占用多大的内存？占用哪里的内存呢？jdk1.4默认的单个线程是占用256k的内存jdk1.5+默认的单个线程是占用1M的内存可以通过-Xss参数设定，一般默认就好这TM还用问？java线程当然是占用jvm的内存啊！

们的服务在每次接口被调用时，都实例化一个ParseConfig对象来配置Fastjson反序列的设置，而未禁用ASM代理的情况下，由于每次调用ParseConfig都是一个新的实例，因此永远也检查不到已经创建的代理类，所以Fastjson便不断的创建新的代理类，并加载到metaspace中，最终导致metaspace不断扩张，将机器的内存耗尽。也就是上面被频繁创建的类。我联系上了WCS的值班人，将我们遇到的问题和他们描述了一下，他们回复我们，会在他们本地执行下写入操作的压测，看看能不能复现我们的问题。

我们主要关注 normal object， 这种类型的 Object 的 Markword 一共是 8 个字节（64位），其中 25 位暂时没有使用，31 位存储对象的 hash 值（注意这里存储的 hash 值对根据对象地址算出来的 hash 值，不是重写 hashcode 方法里面的返回值），中间有 1 位没有使用，还有 4 位存储对象的 age（分代回收中对象的年龄，超过 15 晋升入老年代），最后三位表示偏向锁标识和锁标识，主要就是用来区分对象的锁状态（未锁定，偏向锁，轻量级锁，重量级锁）

作为Java程序员，当我们在命令行提交一个Java任务时，一般我们会显性的设置一些参数，最常见的如指定堆内存大小，程序参数等，来满足你程序的运行需求。但是，在设置JVM内存大小时，我建议你最好不要超过32G这个阈值，因为一旦超过，你的原本的内存占用可能会瞬间剧增。为什么？-XX:+UseCompressedClassPointers //压缩类指针-XX:+UseCompressedOops //压缩普通对象指针。

本来不准备写关于G1垃圾回收器的文章，因为网上介绍的文章真的太多了，写出来容易千篇一律，有抄袭的嫌疑。但由于最近工作中遇到了G1垃圾回收期的线上优化问题，查找了很多资料，最终还是决定做一个总结，也希望能对大家有所帮助。G1(Garbage First)垃圾收集器是当今垃圾回收技术最前沿的成果之一。早在JDK7就已加入JVM的收集器大家庭中，成为HotSpot重点发展的垃圾回收技术，JDK9 默认就是使用的G1垃圾收集器。G1其实是Garbage First的意思，垃圾优先?不是，是。

在 Java8 中彻底移除了永久代，把将类的元数据信息、常量、静态变量、即时编译器编译后的代码从永久代中移到了元空间中。永久代中的类信息一般是在应用程序运行期间不会发生变化的，因此，如果开启了永久代的垃圾回收，就会造成大量的垃圾回收操作，导致垃圾回收效率低下，甚至会引起应用程序的暂停。在永久代中，常量池是一个非常重要的部分，但是其中的常量无法被回收，即使这些常量已经不再被使用，也无法被垃圾回收器回收，这会浪费内存。永久代的大小一旦被设置，就无法动态调整，如果预估错误，就可能导致浪费内存或内存不足的问题。

final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) { Node<K,V>[] tab; Node<K,V> p; int n, i; // 首次添加元素时 if ((tab = tab...

主流的垃圾收集器基本上都是基于可达性分析算法来判定对象是否存活的。根据对象是否被垃圾收集器扫描过而用白、灰、黑三种颜色来标记对象的状态的一种方法。而其中白色：表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始阶段，所有的对象都是白色的，若在分析结束之后对象仍然为白色，则表示这些对象为不可达对象，对这些对象进行回收。灰色：表示对象已经被垃圾收集器访问过，但是这个对象至少存在一个引用（属性）还没有被扫描过。黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经被扫描过。

通过计算历史minor gc后进入老年代对象的平均总大小，如果这个值不大于老年代连续可用空间的总大小，那么就冒险进行minor gc,如果 jvm设置了-XX:HandlePromotionFailure（不允许冒险）或者大于可用空间大小，则还是会做full gc。在发生minor gc之前，jvm会首先检查老年代的可用连续空间是否大于新生代年龄总大小，如果成立，则进行minor gc，并且这个minor gc是安全的，不会触发full gc。

内存多重映射和染色指针的引入，使 ZGC 的并发性能大幅度提升。ZGC 只有 3 个需要 STW 的阶段，其中初始标记和初始转移只需要扫描所有 GC Roots，STW 时间 GC Roots 的数量成正比，不会耗费太多时间。再标记过程主要处理并发标记引用地址发生变化的对象，这些对象数量比较少，耗时非常短。可见整个 ZGC 的 STW 时间几乎只跟 GC Roots 数量有关系，不会随着堆大小和对象数量的变化而变化。ZGC 也有一个缺点，就是浮动垃圾。

ZGC（The Z Garbage Collector）是JDK 11中推出的一款追求极致低延迟的实验性质的垃圾收集器。对于Java项目而言，JVM进行垃圾回收总是绕不开一个问题，那就是Stop The World。对于很多大型项目或对响应时间有要求的项目，垃圾回收的停顿时间就是一个痛点，而ZGC就是一款低延迟的垃圾收集器。

一、来源ZGC收集器是由Oracle公司研发的。2018年创建了JEP 333将ZGC提交给OpenJDK，推动其进入OpenJDK11的发布清单中。二、ZGC的堆内存布局与Shenandoah和G1一样，ZGC也采用基于Region的堆内存布局。 ZGC的Region具有动态性。 动态创建和销毁 动态的区域容量大小 分类如下：小型Region（Small Region）：容量固定为2MB，用于放置小于256KB的小对象。 中型Region（Medium Region）：容

https://www.jianshu.com/p/702eddcac053