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 百万长连接收发消息的压测

有开始,就会有进​步!

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

专家作者推荐

巡山小汪

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

飞哥开发内功

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

踩刀诗人

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

Brand

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

专题推荐

本系列文章主要针对Dubbo2.6.2(dubbox2.8.4)版本,从源码的角度分析Dubbo内部的实现细节,加深对Dubbo的各配置参数底层实现原理的理解,更好的指导Dubbo实践。
11篇文章14468阅读量
GC(Garbage Collection)很大程度上帮助Java程序员解决了内存释放的问题,有了GC,就不需要再手动的去控制内存的释放。
12篇文章30275阅读量