YGC问题排查,又让我涨姿势了!
在高并发下,Java程序的GC问题属于很典型的一类问题,带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」,由于GC期间都存在Stop The World问题,因此很容易导致服务
【全网首发】一些可以显著提高 Java 启动速度方法
我们线上的业务 jar 包基本上普遍比较庞大,动不动一个 jar 包上百 M,启动时间在分钟级,拖慢了我们在故障时快速扩容的响应。于是做了一些分析,看看 Java 程序启动慢到底慢在哪里,如何去优化,目前的效果是大部分大型应用启动时间可以缩短 30%~50%主要有下面这些内容修改 asy
JVM 源码分析之一个 Java 进程究竟能创建多少线程
概述虽然这篇文章的标题打着JVM源码分析的旗号,不过本文不仅仅从 JVM 源码角度来分析,更多的来自于 Linux Kernel 的源码分析,今天要说的是 JVM 里比较常见的一个问题。这个问题可能有
一次完整的JVM堆外内存泄漏故障排查记录
前言记录一次线上JVM堆外内存泄漏问题的排查过程与思路,其中夹带一些「JVM内存分配的原理分析」以及「常用的JVM问题排查手段和工具分享」,希望对大家有所帮助。在整个排查过程中,我也走了不少弯路,但是
记一次Synchronized关键字使用不合理,导致的多线程下线程阻塞问题排查
在为客户进行性能诊断调优时,碰到了一个Synchronized关键字使用不合理导致多线程下线程阻塞的情况。用文字记录下了问题的整个发现-排查-分析-优化过程,排查过程中使用了我司商业化产品——XLan
一次大量 JVM Native 内存泄露的排查分析(64M 问题)
我们有一个线上的项目,刚启动完就占用了使用 top 命令查看 RES 占用了超过 1.5G,这明显不合理,于是进行了一些分析找到了根本的原因,下面是完整的分析过程,希望对你有所帮助。会涉及到下面这些内容Linux 经典的 64M 内存问题堆内存分析、Native 内存分析的基本套路
线上服务的FGC问题排查,看这篇就够了!
这篇文章以一个Full GC频繁的线上案例作为引子,详细介绍GC的排查过程,另外会结合GC的运行原理给出一份实践指南。内容分成3个部分:从一次Full GC频繁的线上案例说起、GC的运行原理介绍、排查Full GC问题的实践指南
一次 Java 进程 OOM 的排查分析(glibc 篇)
遇到了一个 glibc 导致的内存回收问题,查找原因和实验的的过程是比较有意思的,主要会涉及到下面这些:- Linux 中典型的大量 64M 内存区域问题- glibc 的内存分配器 ptmalloc
官方文档竟然有坑!关于G1参数InitiatingHeapOccupancyPercent的正确认知 #我在性能调优路上的打怪日记#
问题前两天,一个群友在群中提出一个疑问:G1里的XX:InitiatingHeapOccupancyPercent,默认是45。他看网上有两种说法,一种是整个堆占用率超过45%时开始并发标记周期;另一
字节对齐与Java的指针压缩(下)-指针压缩
在上一篇文章[《字节对齐与Java的指针压缩(上)-字节对齐的渊源》](https://heapdump.cn/article/2545511)中我们讲到了字节对齐的部分渊源与Java选择8字节对齐的
记一次类加载失败导致线程阻塞问题排查
作为PerfMa解决方案管理部门的技术专家,我在工作遇见过很多各种问题导致的性能问题,并参与了为客户的系统进行性能诊断调优的全过程。这一次碰到了一个类加载失败导致的性能问题。用文字记录下了问题的整个发
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
记一次堆外内存泄漏排查过程
本文涉及以下内容 开启NMT查看JVM内存使用情况 通过pmap命令查看进程物理内存使用情况 smaps查看进程内存地址 gdb命令dump内存块 背景最近收到运维反馈,说有项目的一个
g1源码之fullGC算法详解
关于g1的gc源码系列解析就剩下fullGC了,其实关于fullGC的源码方面并不是很难,相对于youngGC和mixed GC和并发标记来说,相对好阅读一些,网上也有一些文章是讲述fullGC的源码
Spring Boot引起的“堆外内存泄漏”排查及经验总结
本文来自美团技术团队,作者纪兵https://tech.meituan.com/2019/01/03/spring-boot-native-memory-leak.html 背景为了更好地实现对项目的
高吞吐、低延迟 Java 应用的 GC 优化实践
本篇原文作者是 LinkedIn 的 Swapnil Ghike,这篇文章讲述了 LinkedIn 的 Feed 产品的 GC 优化过程,虽然文章写作于 April 8, 2014,但其中的很多内容和
【全网首发】一次想不到的 Bootstrap 类加载器带来的 Native 内存泄露分析
最近我们线上有同学反馈,java 服务在接入了支持预发的 javaagent 以后会出现缓存的内存增长,去掉 agent 启动以后内存增长正常。于是分析了一下这个问题,写了这篇文章。
JVM源码分析之Metaspace解密
概述metaspace,顾名思义,元数据空间,专门用来存元数据的,它是jdk8里特有的数据结构用来替代perm,这块空间很有自己的特点,前段时间公司这块的问题太多了,主要是因为升级了中间件所致,看到大
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
揪出一个导致GC慢慢变长的JVM设计缺陷
今天要给大家分享的内容和 YGC(Young GC)有关,是我最近碰到的一个案例,希望将排查思路分享给大家,如果大家后面碰到类似的问题,可以直接作为一个经验来排查。 我之前在公众号里其实写过几篇 Y
进程无故消失的破案历程
概述 前段时间公司有个系统的进程老是无故退出,在客户那边好好的,在家里服务器上老是出现,而且出现的时间也没啥规律,当然最终查出来还是有规律的,不过这个规律比较特别。大家看了后面的内容之后就明白了
JVM源码分析之jstat工具原理完全解读
概述jstat是hotspot自带的工具,和java一样也位于`JAVA_HOME/bin`下面,我们通过该工具可以实时了解当前进程的gc,compiler,class,memory等相关的情况,具体
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
Java Reference核心原理分析
带着问题,看源码针对性会更强一点、印象会更深刻、并且效果也会更好。所以我先卖个关子,提两个问题(没准下次跳槽时就被问到)。 - 我们可以用ByteBuffer的allocateDirect方法,申请一
一次线上服务高 CPU 占用优化实践
线上有一个非常繁忙的服务的 JVM 进程 CPU 经常跑到 100% 以上,下面写了一下排查的过程。通过阅读这篇文章你会了解到下面这些知识。- Java 程序 CPU 占用高的排查思路- 可能造成线上
代表Java未来的ZGC深度剖析,牛逼!
JAVA程序最爽的地方是它的GC机制,开发人员不需要关注内存申请和回收问题。同时,JAVA程序最头疼的地方也是它的GC机制,因为掌握JVM和GC调优是一件非常困难的事情。在ParallelOldGC、
警惕大量类加载器的创建导致诡异的Full GC
概述 今天有个同事找我,其实好像之前就找过我,一直因为太忙,后面就忘记他的事了,到今天还没查出原因就又找了过来,现象是系统老是进行Full GC,在启动没过多久就会发生Full GC,这个现象相
g1源码之Mixed GC与ConcurrentMark细节详解
继上次全面刨析了youngGC的源码后,这次笔者又阅读了关于Mixed GC的部分源码,相对于youngGC,Mixed GC部分更好阅读和理解一些(ps:不知道是不是因为已经有了读youngGC代码
一次线上JVM调优实践,FullGC40次/天到10天一次的优化过程
通过这一个多月的努力,将FullGC从40次/天优化到近10天才触发一次,而且YoungGC的时间也减少了一半以上,这么大的优化,有必要记录一下中间的调优过程。对于JVM垃圾回收,之前一直都是处于理论
JVM源码分析之不可控的堆外内存
概述 之前写过篇文章,关于堆外内存的,[JVM源码分析之堆外内存完全解读],里面重点讲了DirectByteBuffer的原理,但是今天碰到一个比较奇怪的问题,在设
关于数组动态扩容导致频繁GC的问题,我还有话说
概述 通过上篇[抓了一个导致频繁GC的鬼--数组动态扩容](https://heapdump.cn/article/123281)关于数组动态扩容导致频繁GC的文章或许GET到了这么一些点 -
注意:两个会导致druid性能下降10倍的参数
druid:阿里巴巴开源的为监控而生的数据库连接池。你看,官方都没有说是高性能数据库连接池,因为,在性能方面,HikariCP会说:我不是针对谁,论性能,在坐的各个数据库连接池都是渣渣。Github
记一次微服务耗时毛刺排查
前段时间的某天,注意到一个服务的平均耗时出现了如下图的毛刺现象。注意到毛刺出现极其规律,每30分钟出现一个毛刺。考虑到这种规律性,并结合服务的流量较小(20 QPS)推测,可能是某个定时请求的接口进行
网络IO 实战篇 :Java电商系统:重大事故!IO问题引发线上20台机器同时崩溃
几年前的一个下午,公司里码农们正在安静地敲着代码,突然很多人的手机同时“哔哔”地响了起来。本来以为发工资了,都挺高兴!打开一看,原来是告警短信 故障回顾告警提示“线程数过多,超出阈值”,“CPU空闲率
spring boot 引起的 “堆外内存泄漏”
背景组内一个项目最近一直报swap区域使用过高异常,笔者被叫去帮忙查看原因。发现配置的4G堆内内存,但是实际使用的物理内存高达7G,确实有点不正常,JVM参数配置是:```java-XX:Metasp
从CMS到G1:LinkedIn个人主页调优实战
LinkedIn中的个人主页是访问量最多的页面之一,它允许其他人访问你的个人主页,从而了解你的专业技能,经验和兴趣等: 所以,确保用户访问主页时以最快的速度返回是非常重要的。这篇文章,将谈论Li
不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
实战:OOM 后我如何分析解决的
现在很多面试官都会关心你是否有过解决内存泄漏的问题,是否有过JVM的调优经验。你如果没有经历过,该如何回答呢?希望下文对你有所帮助。 背景前不久,上线了一个新项目,这个项目是一个压测系统,可以简单的看
一次百万长连接压测 Nginx OOM 的问题排查分析
在最近的一次百万长连接压测中,32C 128G 的四台 Nginx 频繁出现 OOM,出现问题时的内存监控如下所示。排查的过程记录如下。 现象描述这是一个 websocket 百万长连接收发消息的压测
深入理解 G1 的 GC 日志
本文基于1.8.0_201-b09对G1的GC日志进行分析。G1 模式下总计有 3 中日志级别,分别被称为:fine,finer,finest。- fine:fine模式打开方式是-verbose:g
分析和解决JAVA 内存泄露的实战例子
这几天,一直在为Java的“内存泄露”问题纠结。Java应用程序占用的内存在不断的、有规律的上涨,最终超过了监控阈值。福尔摩 斯不得不出手了! 分析内存泄露的一般步骤 如果发现Java应用程序占用的内
不可逆的类初始化过程
类的加载过程说复杂很复杂,说简单也简单,说复杂是因为细节很多,比如说今天要说的这个,可能很多人都不了解;说简单,大致都知道类加载有这么几个阶段,loaded-linked-initialized,为了
JVM源码分析之栈溢出完全解读
概述之所以想写这篇文章,其实是因为最近有不少系统出现了栈溢出导致进程crash的问题,并且很隐蔽,根本原因还得借助coredump才能分析出来,于是想从JVM实现的角度来全面分析下栈溢出的这类问题,或
记一次JVM堆外内存泄露Bug的查找
前言JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存,同时对物理内存的使用做了定量的分析,从而实锤了Bug的源头。笔者将此Bug分析的过程写成博客,以飨
改善 Kubernetes 上的 JVM 预热问题
JVM 预热是一个非常头疼而又难解决的问题。本文讨论了在运行在 Kubernetes 集群中的 Java 服务如何解决 JVM 预热问题的一些方法和经验。 作者:Vikas Kumar 翻译:Bach
JVM参数系列 - 学习JVM参数前必须了解的
可以把JVM想象成相机,JVM参数想象成光圈大小,快门速度之类的参数值,这些参数对程序的运行会影响挺大。
频繁操作本地缓存导致YGC耗时过长
某天,某位群友在JVM讨论群里发来一张GC log的图片。其中主要的问题是YGC过长,每次耗时约为200ms。使用的JVM参数如下:```java-Xmn2048m -Xms4096m -Xmx409
OutOfMemoryError之unable to create new native thread原因分析及6种解决方案
java.lang.OutOfMemoryError:unable to create new native thread 是比较常见的一种异常,表示应用程序无法创建新的线程。产生该异常,总体上可总结
JVM Code Cache空间不足,导致服务性能变慢
有业务反馈,线上一个应用运行了一段时间之后,在高峰期之后,突然发现处理能力下降,接口的响应时间变长,但是看Cat上的GC数据,一切都很正常。通过跳板机上机器查看日志,发现一段平时很少见到的日志:```
AsyncGetCallTrace 源码深度剖析
前言 AsyncGetCallTrace 是由 OracleJDK/OpenJDK 内部提供的一个函数,该函数可以在 JVM 未进入 safepoint 时正常获取到当前线程的调用栈(换句话说,使用
又抓了一个导致频繁GC的鬼--数组动态扩容
概述 本周有个同事过来咨询一个比较诡异的gc问题,大概现象是,系统一直在做cms gc,但是老生代一直不降下去,但是执行一次jmap -histo:live之后,也就是主动触发一次full gc之后
GC一些长时间停顿问题排查及解决办法
对于许多企业级应用,尤其是OLTP应用来说,长暂停很可能导致服务超时,而对这些运行在JVM上的应用来说,垃圾回收(GC)可能是长暂停最主要的原因。本文将描述一些可能碰到GC长暂停的不同场景,以及说明我
ZGC什么时候会进行垃圾回收
以往的一些GC算法,比如CMS、G1,均采用分代的思想对堆内存进行划分,对应的GC行为也可以分为Young GC、Old GC 和 FGC。但是在ZGC算法中,并没有分代的概念,所以就不存在Young
XPocket插件jstack_x助力线程问题排查
在程序开发过程中,开发人员通常会遇到许多线上问题,这些问题可能是代码Bug导致的,也可能是性能问题引起的。这些线上问题都会通过CPU飙升、GC频繁、抛出OOM异常等情况表现出来,这些问题的根因很可能是
使用NMT和pmap解决JVM资源泄漏问题
编者按:笔者使用JDK自带的内存跟踪工具NMT和Linux自带的pmap解决了一个非常典型的资源泄漏问题。这个资源泄漏是由于Java程序员不正确的使用Java API导致的,使用Files.list打
一次 JVM 进程退出分析
最近我们在测试把 APM 平台迁移到 ES APM,有同学反馈了一个有意思的现象,部署在 docker 中 jar 包项目,在新版 APM 里进程启动完就退出了,被 k8s 中无限重启。这篇文章写了一
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
一次线上 xxl-job 服务异常排查分析
问题描述某天收到频繁的告警邮件,定时任务调度失败,查看 xxl-job 的执行器列表是空的,但是服务又显示健康,查看历史任务执行记录发现执行器是依次递减,由于是线上服务,只能先重启,然后线程日志也没有
JVM Bug:多个线程持有一把锁?
JVM线程dump Bug描述 在JAVA语言中,当同步块(`Synchronized`)被多个线程并发访问时,JVM中会采用基于互斥实现的重量级锁。JVM最多只允许一个线程持有这把锁,如果其它线
深(浅)入(出)剖析G1(Garbage First)
Java从JDK7U9开始支持G1(正式发布),所以,如果要使用G1的话,你的Java版本应该是JDK7U9或者更新的版本。不过,强烈建议JDK8才使用G1,而且最好是JDK8的最新版本,因为在JDK
聊一个可能有惊喜的System GC知识点
问题概述因为工作关系有挺长时间没和大家分享东西了,也经常看到有同学在后台给我留言说好久没更新了,实在抱歉,不过接下来会有比较多的分享给到大家,下周我们会在PerfMa的社区(https://club.
深入理解堆外内存 Metaspace
在之前介绍的分代垃圾回收算法中,我们一直有一个永久代存在,叫 PermGen,内存上它是挨着堆的。为了垃圾回收方便,HotSpot 在永久代上一直是使用老年代的垃圾回收算法。永久代主要存放以下数据:-
Java 应用性能调优的一些实践
Java 应用性能优化是一个老生常谈的话题,典型的性能问题如页面响应慢、接口超时,服务器负载高、并发数低,数据库频繁死锁等。尤其是在“糙快猛”的互联网开发模式大行其道的今天,随着系统访问量的日益增加和
一次真实的线上OOM问题定位
概述近日,负责的一系统生产环境上出现了OutOfMemoryError,伴随着这个问题随之而来的是一堆Full GC, CPU 百分之百,频繁宕机重启等问题,严重影响业务的推广及使用,此类问题一般处理
JVM源码分析之警惕存在内存泄漏风险的FinalReference(增强版)
概述JAVA对象引用体系除了强引用之外,出于对性能、可扩展性等方面考虑还特地实现了四种其他引用:SoftReference、WeakReference、PhantomReference、FinalRe
JVM 发生 OOM 的 8 种原因、及解决办法
小A:xx服务又宕机了小B:歪日,咋搞的,登上去看看咋回事小A:又OOM了,不知道哪个写的代码,一坨一样。撸Java的同学,多多少少会碰到内存溢出(OOM)的场景,但造成OOM的原因却是多种多样。 堆
JVM源码分析之JDK8下的僵尸(无法回收)类加载器
概述这篇文章基于最近在排查的一个问题,花了我们团队不少时间来排查这个问题,现象是有一些类加载器是作为key放到WeakHashMap里的,但是经历过多次full gc之后,依然坚挺地存在内存里,但是从
高并发下的 AtomicLong 性能有点差!
如果让你实现一个计数器,有点经验的同学可以很快的想到使用AtomicInteger或者AtomicLong进行简单的封装。因为计数器操作涉及到内存的可见性和线程之间的竞争,而Atomic的实现完美的屏
一个 JVM 参数引发的频繁 CMS GC
前言了解 CMS GC 的同学,一定知道 -XX:CMSScavengeBeforeRemark 参数,它是用来开启或关闭在 CMS-remark 阶段之前的清除(Young GC)尝试。大家都知道C
Redis client链接池配置不当引起的频繁full gc
现象笔者负责的一个RPC服务就是简单的从Redis Cluster中读取数据,然后返回给上游。理论上该服务的对象大部分都应该是朝生夕死的,但是笔者查看gc log 的时候发现 age =2 的对象还真
FullGC实战:业务小姐姐查看图片时一直在转圈圈
业务小姐姐说图片访问不了,我开始慌了:看到业务小姐姐发的这个图片,你说能不慌嘛?但是再慌也要排查问题呀!对于这种前端响应不过来的问题,首先就用浏览器的F12看看接口响应速度(获取图片地址的接口)从而确
Docker对JVM一些限制的研究
首先说一个老生常谈的限制:我们在对Docker中的Java应用使用诸如jmap等命令时常常会报错:`Can't attach to the process: ptrace(PTRACE_ATTACH,
Java OOM 实战篇:应用故障之Java heap space 堆溢出实战
以下是用于测试OOM的测试代码:```javapublic class HeapMemUseTest { public static void main(String[] args) {
一次年轻代GC长暂停问题的解决与思考
问题描述公司某规则引擎系统,在每次发版启动会手动预热,预热完成当流量切进来之后会偶发的出现一次长达1-2秒的年轻代GC(流量并不大,并且LB下的每一台服务都会出现该情况)在这次长暂停之后,每一次的年轻
GC 实战—浮动内存导致的 CPU 过高调优
由于接入的应用越来越多,对系统性能要求越来越高,提高系统的吞吐率,以及提升性能,是我们春节战役期间必须要做的事情。系统的性能优化不单单是对 JVM 的参数调优,也不是某一段代码的改造,而是一个系统的工
fastJson与一起堆内存溢出'血案'
现象- QA同学反映登录不上服务器 排查问题1--日志级别- 查看log,发现玩家登录的时候抛出了一个java.lang.OutOfMemoryError - 大概代码是向Redis序列化一个Pla
为什么容器内存占用居高不下,频频 OOM(续)
在之前的文章《[为什么容器内存占用居高不下,频频 OOM](https://heapdump.cn/article/1589003)》 中,我根据现状进行了分析和说明,收到了很多读者的建议和疑
由「Metaspace容量不足触发CMS GC」从而引发的思考
某天早上,毛老师在群里问「cat 上怎么看 gc」。看到有 GC 的问题,立马做出小鸡搓手状,之后毛老师发来一张图。图片展示了老年代内存占用情况:第一个大陡坡是应用发布,老年代内存占比下降,很正常。第
JVM源码分析之自定义类加载器如何拉长YGC
概述本文重点讲述毕玄大师在其公众号上发的一个GC问题一个jstack/jmap等不能用的case,对于毕大师那篇文章,题目上没有提到GC的那个问题,不过进入到文章里可以看到,既然文章提到了jstack
JVM菜鸟进阶高手之路三Tomcat调优
因为每个链路都会对其性能造成影响,应该是全链路的修改压测(ak大神经常说全链路!)。本次基本就是局域网,所以并没有怎么优化,其实也应该考虑进去的。 Linux系统参数层面的修改:修改可打开文件数和用户
JVM 源码解读之 CMS 何时会进行 Full GC
前言 本文内容是基于 JDK 8在文章[ JVM 源码解读之 CMS GC 触发条件](https://heapdump.cn/article/190389) 中分析了 CMS GC 触发的
JVM菜鸟进阶高手之路二MAT工具相关知识解惑
关于MAT工具相关知识解惑MAT 不是一个万能工具,它并不能处理所有类型的堆存储文件。但是比较主流的厂家和格式,例如 Sun, HP, SAP 所采用的 HPROF 二进制堆存储文件,以及 IBM 的
一则OOM死机故障的处理过程
OOM是Out of Memory的简写,也就是内存不足。出现该问题的原因有很多,如程序内存泄漏等。内存泄漏问题可以通过定时地终止和重启有问题的程序来发现和解决。在比较新的Linux内核版本中,有一种
Elasticsearch调优篇-慢查询分析笔记
前言- elasticsearch提供了非常灵活的搜索条件给我们使用,在使用复杂表达式的同时,如果使用不当,可能也会为我们带来了潜在的风险,因为影响查询性能的因素很多很多,这篇笔记主要记录一下慢查询可
一次线上JVM Young GC调优,搞懂了这么多东西!
先说一下基本情况,本次是对线上商品服务的JVM优化。商品服务的访问量非常高,单机QPS在3000左右,线上总共部署了15个商品服务节点。JVM堆内存大小是8G,其中给新生代分配了2G,老年代垃圾回收器
为什么容器内存占用居高不下,频频 OOM
最近我在回顾思考(写 PPT),整理了现状,发现了这个问题存在多时,经过一番波折,最终确定了元凶和相对可行的解决方案,因此分享一下排查历程,希望能够给大家一些借鉴的经验。时间线:- 在上 Kubern
JVM源码分析之Attach机制实现完全解读
Attach是什么在讲这个之前,我们先来点大家都知道的东西,当我们感觉线程一直卡在某个地方,想知道卡在哪里,首先想到的是进行线程dump,而常用的命令是jstack ,我们就可以看到如下线程栈了大家是
JDK11现存性能bug(JDK-8221393)深度解析
这是一篇鸽了很久的博客,因为博客内容和素材早就准备差不多了,但就是一直懒得整理,今天终于下定决心终于整理出来了,这也是这个bug [JDK-8221393](https://bugs.openjdk.
FGC实战:坏代码导致服务频繁FGC无响应问题分析
前些日子小组内安排值班,轮流看顾我们的服务,主要做一些报警邮件处理、Bug 排查、运营 issue 处理的事。工作日还好,无论干什么都要上班的,若是轮到周末,那这一天算是毁了。不知道是公司网络广了就这

有开始,就会有进​步!

在追求性能的道路上,记录每一刻的成长!源码解读,编程技巧,外文翻译,技术实践,线上案例等等,记录自己,启发他人!

专家作者推荐

巡山小汪

关注微信公众号《解Bug之路》,有问题请在公众号中咨询:) 无论多么艰苦的时刻,都不要忘记,辉煌的未来,在你的眼中闪耀!

飞哥开发内功

《深入理解Linux网络》作者,腾讯搜狗十年工程师,公众号「开发内功修炼」作者!

踩刀诗人

聊聊技术,唠唠段子,偶尔做菜写诗,欢迎关注我的公众号 踩刀诗人

Brand

搜索关注微信公众号【架构与思维】:撰稿者为bat、字节的几位高阶研发/架构,专注技术分享。

专题推荐

同 CPU 管理一样,内存管理也是操作系统最核心的功能之一。内存主要用来存储系统和应用程序的指令、数据、缓存等。
8篇文章20812阅读量
互联网场景中经常使用消息中间件进行消息路由、订阅发布、异步处理等操作,来缓解系统的压力;在高并发、高消息吞吐的互联网场景中,我们经常会使用消息队列(Message Queue)作为基础设施,在服务端架构中担当消息中转、消息削峰、事务异步处理 等职能。对于那些不需要实时响应的的业务,我们都可以放在消息队列中进行传输~
13篇文章27872阅读量