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

有开始,就会有进​步!

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

专家作者推荐

巡山小汪

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

飞哥开发内功

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

踩刀诗人

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

Brand

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

专题推荐

Netty 是一个异步事件驱动的网络通信层框架,用于快速开发高可用高性能的服务端网络框架与客户端程序,它极大地简化了 TCP 和 UDP 套接字服务器等网络编程。
作者:闪电侠,《跟闪电侠学 Netty》已出版了。书的前半部分是掘金小册中的内容:通过一个完整的 IM 项目入门 Netty;后半部分用了较大的篇幅来介绍 Netty 的底层原理,也会穿插讲一些源码阅读的思路,希望能够帮助到你。
13篇文章21840阅读量
Out of memory (OOM) 是一种操作系统或者程序已经无法再申请到内存的状态。经常是因为所有可用的内存,包括磁盘交换空间都已经被分配了。OOM的官方解释是:Understand the OutOfMemoryError Exception,根据HeapDump性能社区专属讲师公与的总结,常见的OOM有以下10种(其中OOM Killer是操作系统层面的概念)。
11篇文章12748阅读量