“ 这篇文章给大家聊一次线上生产系统事故的解决经历，其背后代表的是线上生产系统的JVM FullGC可能引发的严重故障。
下载问题是什么问题 ⽤户线程访问所导致的⼤对象问题 解决这个问题的关键是什么 32G内存-xmx30G，系统每次进⾏FullGC时⻓太⻓ 可以减少-xmx⼤⼩成4G，从⽽缩短Full GC 最终解决⽅
JVM面试题 字节码相关 知道字节码吗?字节码都有哪些? JMM内存模型 说说JVM的主要组成部分以及作用? jvm内存模型，内存屏障 对象一定分配在堆栈对象不一定分配在堆上，JIT可以实现栈上分配
Tech 导读 本文记录了一次排查FullGC导致的TP99过高过程，介绍了一些排查时思路，线索以及工具的使用，希望能够帮助一些新手在排查问题没有很好的思路时，提供一些思路，让小白也能轻松解决FullGC问题；文中实际提到的参数配置不一定适合其他业务场景，在调优自己的项目时还是需要实际试验过才能得出最佳参数配置。
Tech 导读 本文是线上问题处理案例分析，旨在通过真实案例向读者介绍发现问题、定位问题、解决问题的方法。本文讲述了从垃圾回收耗时过长的表象，逐步定位到数据库连接池保活问题的全过程，并对其中用到的一些知识点进行了总结。
这几天xx病毒在成都又开始抬头了。响应国家号召，成都市民从9月1日起开始居家，并开始了三天三检。相信大家已经知道了，就是这边的核酸登记系统崩溃了。
通过这一个多月的努力，将FullGC从40次/天优化到近10天才触发一次，而且YoungGC的时间也减少了一半以上，这么大的优化，有必要记录一下中间的调优过程。
【对于正常运行的系统】 使用jmap来查看JVM中各个区域的使用情况。 使用jstack来查看线程的运行情况，比如：哪些线程阻塞、是否出现了死锁。 使用jstat命令来查看垃圾回收情况，特别是fullGC，如果fullGC比较频繁，那么就得进行调优了 初步猜测频繁发生fullGC的原因。如果频发发生fullGC但是却一直没有出现内存溢出，那么表示fullGC实际上是回收了很多对象了，所以这些对象最好能在youngGC里就直接回收掉，避免这些对象进入老年代。对于这种情况，就要考虑这些存活时间不长的对象是不是比
在某个工作日，突然收到线上的服务告警，有大量的请求延时产生，查看线上服务发现基本上都是获取数据库连接超时，而且影响时间只有34秒钟，服务又恢复了正常。隔了几分钟之后，又出现了大量的告警，还是影响34秒后又恢复正常。 由于我们是底层服务，被重多的上层服务所依赖，这么频繁的异常波动已经严重影响到了业务使用。开始排查问题
上线新功能后，要多观察。如果出现不稳定性的情况，需要高优先级查清原因，避免出现更大的问题。
在G1出来之前，CMS绝对是OLTP系统的标配。即使G1出来几年了，生产环境很多的JVM实例还是采用ParNew+CMS的组合。但是即使其得到这么广泛的应用，还是有很多同学对它有很深的误解。本文主要对ParNew+CMS经典组合下，触发的几种垃圾回收方式进行几个概念的纠正。
导读：本文记录一次线上JVM调优实践，FullGC40次/天到10天一次的优化过程，总结本篇文章希望对从事相关工作的同学能够有所帮助或者启发。
在日常后端开发中,部分业务都是接收MQ消息,在消费消息的过程中,会调用外部的Dubbo接口,根据接口返回数据,做一些业务逻辑处理.如下图
简单介绍下我们服务的背景，我们的服务是一个使用类似dubbo的RPC框架以及若干Spring全家桶组合起来的微服务架构，大致结构可以参考下图。Java服务使用的是CMS的垃圾回收器。
公众号改版后文章乱序推荐，希望你可以点击上方“Java进阶架构师”，点击右上角，将我们设为★“星标”！这样才不会错过每日进阶架构文章呀。
上篇文章说了G1不在是连续的老年代年轻代，而是分为不同的region，有eden，survivor，old，humongous，当大于百分之50region的数据则直接进入humongous，如果对象太大，会连续的存储，分为初始标记，并发标记，最终标记，筛选标记，其中只有并发标记不会STW，G1可以设置STW的时候，从而利用成本算法排序回收一部分垃圾。
简介：FullGC与MinorGC讲解 Minor GC触发条件 当Eden区满时，触发Minor GC FullGC触发条件 调⽤ System.gc() 此⽅法的调⽤是建议 JVM 进⾏ Full GC，虽然只是建议⽽⾮⼀定，但很多情况下它会触发 Full GC。因此强烈建议能不使⽤此⽅法就不要使⽤，让虚拟机⾃⼰去管理它的内存。可通过 -XX:+ DisableExplicitGC 来禁⽌ RMI 调⽤ System.gc() ⽼年代空间不⾜ ⽼年代空间不⾜的常⻅场景为前⽂所讲的⼤对象直接进⼊⽼年代、
上篇文章说了CMS垃圾收集器是赋值清除，所以他不可以碎片整理，于是jvm支持两个参数，几次fullGC之后碎片整理压缩空间。Cms他会抢占cpu资源，因为是并行运行，所以会有浮动垃圾。还有执行不确定性，垃圾收集完，继续进入新的对象，导致异常concurrent mode faliture，最后用serial old处理，可以用jvm的fraction参数来参数百分之多少的时候需要GC，这样就预留充足的空间存储新对象。
今天下午把 JavaGuide[1]上 MySQL 以及书单部分的内容完善了一下。
我猜你肯定是为了面试，现在很多公司都会问这个，虽然你工作了N年JVM调优可能都不会接触到，但我觉得还是有考察的必要的。因为很多时候我们考察一个人不光要考察他的硬实力，还要看他有没有持续学习、深入研究的精神，一只咸鱼是不会看JVM调优的。
Tech 导读 机器扩容后瞬间被高流量击穿，背后发生了什么？本文从实际案例入手，探讨在冷启动的场景下如何保护系统不被瞬间流量压垮。
最近和一些同学交流的时候反馈说，在面试Kafka时，被问到Kafka组件组成部分、API使用、Consumer和Producer原理及作用等问题都能详细作答。但是，问到一个平时不注意的问题，就是Kafka的幂等性，被卡主了。那么，今天笔者就为大家来剖析一下Kafka的幂等性原理及实现。
当前处于 Active 状态的 ResourceManager 转成 StandBy 状态，原先处于 StandBy 状态的 ResourceManager 转成 Active 状态
在本地针对项目的登录接口做了一次简单的压力测试。200并发持续120s，观察吞吐量
相信大家都遇到过内存溢出的情况，内存溢出一般会使系统崩溃，甚至还会使服务卡死。所以规避内存溢出和及时解决内存溢出尤为重要。
当我们系统上线，但我们感觉并没有把代码上线，或者上错分支，这时候怎么办呢，于是可以用这个命令来反编译代码，看看是否正常。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误：
线上有Tomcat升级到7.0.52版，然后有应用的JVM FullGC变频繁，在高峰期socket连接数，Cpu使用率都暴增。
产生400报错的原因是es7做了熔断优化，当jvm内存使用超过阈值，为了避免丑陋的oom，会直接限流并抛出EsRejectedExecutionException。
新版的dubbo-admin 在支持dubbo2.7新特性的同时，还兼容dubbo2.6。基于dubbo2.7的元数据中心，我们可以做一些事情，比如服务测试，在目前版本的dubbo-admin中，其实已经支持这个功能。
近期遇到了两个线上服务的问题，一个后端应用和一个前端项目，它们存在一些 bug 和历史遗留问题。为了不影响用户的使用体验，决定对它们进行一次优化。
什么是gcroot，JVM在进⾏垃圾回收时，需要找到“垃圾”对象，也就是没有被引⽤的对象，但是直接找“垃圾”对象是⽐较耗时的，所以反过来，先找“⾮垃圾”对象，也就是正常对象，那么就需要从某些“根”开始去找，根据这些“根”的引⽤路径找到正常对象，⽽这些“根”有⼀个特征，就是它只会引⽤其他对象，⽽不会被其他对象引⽤，例如：栈中的本地变量、⽅法区中的静态变量、本地⽅法栈中的变量、正在运⾏的线程等可以作为gcroot。
首先通过我们内部搭建的日志平台发现我们线上环境一个java应用有大量的http接口请求超时，登录linux服务器查看网络环境没有问题，判断是应用自身运行异常，重启应用后发现异常还在，开始查找问题。
初始标记会触发 stop the world ，从垃圾回收的根对象开始查找，这个过程会暂停整个JVM，但是很快结束
这个机制的目的是为了提升效率，在minorGC之前，会有三次判断，之后再次minorGC速度会很快。
前面还有一个类的加载没说，类的加载则需要考虑到双亲委派，有三个类自带的核心加载器，bootStrap加载器，扩展加载器，app加载器，后面则有自定义加载器。
JVM把内存区分为堆区(heap)、栈区(stack)和方法区(method)。由于本文主要讲解JVM调优，因此我们可以简单的理解为，JVM中的堆区中存放的是实际的对象，是需要被GC的。其他的都无需GC。
总之，调优不是一蹴而就的，需要分析、推理、实践、总结、再分析，最终定位到具体的问题
在前面的引用计数法和可达性算法一文中，我们讲了一个引用要被回收需要达到的条件以及怎么判断一个引用是否要被回收。了解了这些知识，就到了今天要讲的垃圾收集算法。
链接:[#link]( https://www.cnblogs.com/duanxz/p/3482366.html )
了解 Redis 的同学都知道它是一个纯内存的数据库，凭借优秀的并发和易用性打下了互联网项的半壁江山。Redis 之所以高性能是因为它的纯内存访问特性，而这也成了它致命的弱点 —— 内存的成本太高。所以在绝大多数场合，它比较适合用来做缓存，长期不被访问的冷数据被淘汰掉，只有热的数据缓存在内存中，这样就不会浪费太多昂贵的内存空间。
本文旨在概述京东在JDK方向上的尝试与探索，以及京东JDK项目背景，基本特性以及未来的工作方向。 对于JDK特性的技术讨论，实现细节及效果，将在后续系列文章中深入讨论。
从监控系统来看，被 kill 的节点 A 在重启前，堆内存使用随着 YoungGC 规律波动，元空间占用较高，且一直缓慢增长到了400MB以上——该应用代码量不大，按理不应该占用这么多。
1、OOM异常：java.lang.OutOfMemoryError: Java heap space
其中New和Tenured属于堆内存，堆内存会从JVM启动参数（-Xmx:3G）指定的内存中分配，Perm不属于堆内存，有虚拟机直接分配，但可以通过-XX:PermSize -XX:MaxPermSize 等参数调整其大小。
标记-清除算法分为标记和清除两个阶段：首先标记出需要回收的对象，在标记完成后统一回收所有被标记的对象。 存在的问题： 一是效率低，标记和清除两个过程效率都不高。二是空间问题，标记清除后会产生大量的不连续的内存碎片。空间碎片太多会导致程序在运行过程中需要分配较大对象时无法找到连续内存而不得不提前触发GC。
接下来，dump内存，这里注意一点，dump时切记让运维同学把dump的机器从集群中摘掉，否则dump时会造成JVM线程停顿，导致超时告警，影响业务。dump结果使用MAT(Eclipse Memory Analyzer)分析，具体截图就不展示了，从支配树上可以看出，某个缓存对象占用空间很大，个数非常多。从业务代码中查看，发现该对象是个本地缓存对象(Guava Cache)，缓存3分钟，而且是个配置项，按照不同业务线、城市，总共才500个，每个配置项比较小，怎么会突然占用这么大空间呢？使用jstat命令查看系统的垃圾回收统计情况，发现YGC大概每10s一次，对于一个对象，即在年轻代中驻留约15*10=150s，再晋升到老年代，也就是在缓存有效期内，缓存对象足够晋升到老年代，缓存失效时，则会创新创建对象放入缓存。初步结论是：缓存过期时间过小导致对象晋升到老年代过快。
首先要明白学习的目的，不同阶段，不同技术的学习目的是不一样的。 有些技术，仅仅是应用级别的，有些技术是原理级别的（主要还是应试）。所以不同技术、不同时间学习方式需要改变。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
