YGC问题排查,又让我涨姿势了!
在高并发下,Java程序的GC问题属于很典型的一类问题,带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」,由于GC期间都存在Stop The World问题,因此很容易导致服务
JVM 源码分析之一个 Java 进程究竟能创建多少线程
概述虽然这篇文章的标题打着JVM源码分析的旗号,不过本文不仅仅从 JVM 源码角度来分析,更多的来自于 Linux Kernel 的源码分析,今天要说的是 JVM 里比较常见的一个问题。这个问题可能有
一次完整的JVM堆外内存泄漏故障排查记录
前言记录一次线上JVM堆外内存泄漏问题的排查过程与思路,其中夹带一些「JVM内存分配的原理分析」以及「常用的JVM问题排查手段和工具分享」,希望对大家有所帮助。在整个排查过程中,我也走了不少弯路,但是
记一次Synchronized关键字使用不合理,导致的多线程下线程阻塞问题排查
在为客户进行性能诊断调优时,碰到了一个Synchronized关键字使用不合理导致多线程下线程阻塞的情况。用文字记录下了问题的整个发现-排查-分析-优化过程,排查过程中使用了我司商业化产品——XLan
一次 Java 进程 OOM 的排查分析(glibc 篇)
遇到了一个 glibc 导致的内存回收问题,查找原因和实验的的过程是比较有意思的,主要会涉及到下面这些:- Linux 中典型的大量 64M 内存区域问题- glibc 的内存分配器 ptmalloc
官方文档竟然有坑!关于G1参数InitiatingHeapOccupancyPercent的正确认知 #我在性能调优路上的打怪日记#
问题前两天,一个群友在群中提出一个疑问:G1里的XX:InitiatingHeapOccupancyPercent,默认是45。他看网上有两种说法,一种是整个堆占用率超过45%时开始并发标记周期;另一
高吞吐、低延迟 Java 应用的 GC 优化实践
本篇原文作者是 LinkedIn 的 Swapnil Ghike,这篇文章讲述了 LinkedIn 的 Feed 产品的 GC 优化过程,虽然文章写作于 April 8, 2014,但其中的很多内容和
JVM源码分析之jstat工具原理完全解读
概述jstat是hotspot自带的工具,和java一样也位于`JAVA_HOME/bin`下面,我们通过该工具可以实时了解当前进程的gc,compiler,class,memory等相关的情况,具体
Java Reference核心原理分析
带着问题,看源码针对性会更强一点、印象会更深刻、并且效果也会更好。所以我先卖个关子,提两个问题(没准下次跳槽时就被问到)。 - 我们可以用ByteBuffer的allocateDirect方法,申请一
代表Java未来的ZGC深度剖析,牛逼!
JAVA程序最爽的地方是它的GC机制,开发人员不需要关注内存申请和回收问题。同时,JAVA程序最头疼的地方也是它的GC机制,因为掌握JVM和GC调优是一件非常困难的事情。在ParallelOldGC、
一次线上JVM调优实践,FullGC40次/天到10天一次的优化过程
通过这一个多月的努力,将FullGC从40次/天优化到近10天才触发一次,而且YoungGC的时间也减少了一半以上,这么大的优化,有必要记录一下中间的调优过程。对于JVM垃圾回收,之前一直都是处于理论
实战:OOM 后我如何分析解决的
现在很多面试官都会关心你是否有过解决内存泄漏的问题,是否有过JVM的调优经验。你如果没有经历过,该如何回答呢?希望下文对你有所帮助。 背景前不久,上线了一个新项目,这个项目是一个压测系统,可以简单的看
分析和解决JAVA 内存泄露的实战例子
这几天,一直在为Java的“内存泄露”问题纠结。Java应用程序占用的内存在不断的、有规律的上涨,最终超过了监控阈值。福尔摩 斯不得不出手了! 分析内存泄露的一般步骤 如果发现Java应用程序占用的内
不可逆的类初始化过程
类的加载过程说复杂很复杂,说简单也简单,说复杂是因为细节很多,比如说今天要说的这个,可能很多人都不了解;说简单,大致都知道类加载有这么几个阶段,loaded-linked-initialized,为了
记一次JVM堆外内存泄露Bug的查找
前言JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存,同时对物理内存的使用做了定量的分析,从而实锤了Bug的源头。笔者将此Bug分析的过程写成博客,以飨
改善 Kubernetes 上的 JVM 预热问题
JVM 预热是一个非常头疼而又难解决的问题。本文讨论了在运行在 Kubernetes 集群中的 Java 服务如何解决 JVM 预热问题的一些方法和经验。 作者:Vikas Kumar 翻译:Bach
OutOfMemoryError之unable to create new native thread原因分析及6种解决方案
java.lang.OutOfMemoryError:unable to create new native thread 是比较常见的一种异常,表示应用程序无法创建新的线程。产生该异常,总体上可总结
JVM Code Cache空间不足,导致服务性能变慢
有业务反馈,线上一个应用运行了一段时间之后,在高峰期之后,突然发现处理能力下降,接口的响应时间变长,但是看Cat上的GC数据,一切都很正常。通过跳板机上机器查看日志,发现一段平时很少见到的日志:```
又抓了一个导致频繁GC的鬼--数组动态扩容
概述 本周有个同事过来咨询一个比较诡异的gc问题,大概现象是,系统一直在做cms gc,但是老生代一直不降下去,但是执行一次jmap -histo:live之后,也就是主动触发一次full gc之后
使用NMT和pmap解决JVM资源泄漏问题
编者按:笔者使用JDK自带的内存跟踪工具NMT和Linux自带的pmap解决了一个非常典型的资源泄漏问题。这个资源泄漏是由于Java程序员不正确的使用Java API导致的,使用Files.list打
一次 JVM 进程退出分析
最近我们在测试把 APM 平台迁移到 ES APM,有同学反馈了一个有意思的现象,部署在 docker 中 jar 包项目,在新版 APM 里进程启动完就退出了,被 k8s 中无限重启。这篇文章写了一
一次线上 xxl-job 服务异常排查分析
问题描述某天收到频繁的告警邮件,定时任务调度失败,查看 xxl-job 的执行器列表是空的,但是服务又显示健康,查看历史任务执行记录发现执行器是依次递减,由于是线上服务,只能先重启,然后线程日志也没有
深(浅)入(出)剖析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 百分之百,频繁宕机重启等问题,严重影响业务的推广及使用,此类问题一般处理
高并发下的 AtomicLong 性能有点差!
如果让你实现一个计数器,有点经验的同学可以很快的想到使用AtomicInteger或者AtomicLong进行简单的封装。因为计数器操作涉及到内存的可见性和线程之间的竞争,而Atomic的实现完美的屏
Java OOM 实战篇:应用故障之Java heap space 堆溢出实战
以下是用于测试OOM的测试代码:```javapublic class HeapMemUseTest { public static void main(String[] args) {
一次年轻代GC长暂停问题的解决与思考
问题描述公司某规则引擎系统,在每次发版启动会手动预热,预热完成当流量切进来之后会偶发的出现一次长达1-2秒的年轻代GC(流量并不大,并且LB下的每一台服务都会出现该情况)在这次长暂停之后,每一次的年轻
一则OOM死机故障的处理过程
OOM是Out of Memory的简写,也就是内存不足。出现该问题的原因有很多,如程序内存泄漏等。内存泄漏问题可以通过定时地终止和重启有问题的程序来发现和解决。在比较新的Linux内核版本中,有一种
Elasticsearch调优篇-慢查询分析笔记
前言- elasticsearch提供了非常灵活的搜索条件给我们使用,在使用复杂表达式的同时,如果使用不当,可能也会为我们带来了潜在的风险,因为影响查询性能的因素很多很多,这篇笔记主要记录一下慢查询可
JVM源码分析之Attach机制实现完全解读
Attach是什么在讲这个之前,我们先来点大家都知道的东西,当我们感觉线程一直卡在某个地方,想知道卡在哪里,首先想到的是进行线程dump,而常用的命令是jstack ,我们就可以看到如下线程栈了大家是
JDK11现存性能bug(JDK-8221393)深度解析
这是一篇鸽了很久的博客,因为博客内容和素材早就准备差不多了,但就是一直懒得整理,今天终于下定决心终于整理出来了,这也是这个bug [JDK-8221393](https://bugs.openjdk.
FGC实战:坏代码导致服务频繁FGC无响应问题分析
前些日子小组内安排值班,轮流看顾我们的服务,主要做一些报警邮件处理、Bug 排查、运营 issue 处理的事。工作日还好,无论干什么都要上班的,若是轮到周末,那这一天算是毁了。不知道是公司网络广了就这
一次诡异的垃圾回收耗时问题排查实践
之前的博文中说过最近在查一个问题,花费了近两个星期,问题算是有了一个小结,是时候总结一下了。排查过程走了很多弯路,由于眼界和知识储备问题,也进入了一些思维误区,希望此问题能以后再查询此类问题时能有所警
踩了一个java命令行参数顺序的坑
前言 这几天线上实例会偶尔报警重启,查了一下问题,偶然发现了一个`java`命令参数顺序的坑。 正文 我线上的启动命令行为: ```sh java -jar app.jar -DcustomArg
导致程序出现OOM的因素,夜深人静的时候,程序OOM异常追踪
作为Java程序员, 除了享受垃圾回收机制带来的便利外, 还深受OOM(Out Of Memory)的困惑和折磨。 堆溢出(heap)编写如下例程:```javapublic static void
大量类加载器创建导致诡异FullGC
现象最近接手了一个同事的项目,某一天接口的响应耗时突然增加了很多,由几十ms 增加到了几十秒。首先查看机器上的日志,有调用第三方接口超时,查询数据库超时。立马查看第三方接口监控和数据库监控,一切正常。
震惊!线上四台机器同一时间全部 OOM,到底发生了什么?
案发现场昨天晚上突然短信收到 APM (即 Application Performance Management 的简称,我们内部自己搭建了这样一套系统来对应用的性能、可靠性进行线上的监控和预警的一种
消失的Java进程-Linux OOM Killer
在一台虚拟机上执行docker java应用,每隔一段时间就会出现java进程消失、而且没有任何jvm error log的情况。略一寻思,应该是遇到网上常说的Linux OOM的情况:虚拟机10G,
谈谈JVM的垃圾回收器
JVM的GC经过多年的发展,大家对Minor GC、major GC的理解并不完全一致,所以我不打算在本文中使用这个概念。我把GC大概分为一下4类:1. Young GC:只是负责回收年轻代对象的GC
记一次简单的 JVM 调优
背景最近对负责的项目进行了一次性能优化,其中包括对 JVM 参数的调整,算是进行了一次简单的 JVM 调优,JVM 参数调整之后,服务的整体性能有 5% 左右的提升,还算不错。先介绍一下项目的基本情况
OOM异常会导致JVM退出吗?
问题来源一次生产事故,由于一次性从数据库查询过多数据导致线程 OOM:Java heap space 异常(千万级表,JVM堆内存2G),但是在线程OOM发生时,java进程却没有立即挂掉。不符合所谓
谈谈项目中主动full gc的一些问题
背景前一段时间在公司一个技术群里,有人在问“有人在线上使用32G内存的服务”。我司线上内存标准配置都是8G的。我就问了一下使用32G内存碰到了啥问题。他的关注点在于一次full gc 时间的长短上。他
强如 Disruptor 也发生内存溢出?
前言```OutOfMemoryError ```问题相信很多朋友都遇到过,相对于常见的业务异常(数组越界、空指针等)来说这类问题是很难定位和解决的。本文以最近碰到的一次线上内存溢出的定位、解决问题的
导致程序出现OOM的因素,夜深人静的时候,程序OOM异常追踪
作为Java程序员, 除了享受垃圾回收机制带来的便利外, 还深受OOM(Out Of Memory)的困惑和折磨.先来看下java的内存分布 堆溢出(heap)编写如下例程:```javapublic
SafePoint 与 Stop The World 全解(基于OpenJDK 11版本)
在分析线上 JVM 性能问题的时候,我们可能会碰到下面这些场景:1.GC 本身没有花多长时间,但是 JVM 暂停了很久,例如下面:2.JVM 没有 GC,但是程序暂停了很久,而且这种情况时不时就出现。
一次 HashSet 所引起的并发问题
背景上午刚到公司,准备开始一天的摸鱼之旅时突然收到了一封监控中心的邮件。心中暗道不好,因为监控系统从来不会告诉我应用完美无 bug,其实系统挺猥琐。打开邮件一看,果然告知我有一个应用的线程池队列达到阈
类初始化死锁导致线程被打爆!打爆!爆!
概述之前写过关于类加载死锁的文章,[消失的死锁](https://heapdump.cn/article/280601),说的是类加载过程中发生的死锁,我们从线程dump里完全看不出死锁的迹象

有开始,就会有进​步!

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

专家作者推荐

巡山小汪

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

飞哥开发内功

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

踩刀诗人

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

Brand

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

专题推荐

分布式系统绕不开的核心之一的就是数据缓存,有了缓存的支撑,系统的整体吞吐量会有很大的提升。通过使用缓存,我们把频繁查询的数据由磁盘调度到缓存中,保证数据的高效率读写。
21篇文章38544阅读量
Netty 是一个异步事件驱动的网络通信层框架,用于快速开发高可用高性能的服务端网络框架与客户端程序,它极大地简化了 TCP 和 UDP 套接字服务器等网络编程。
作者:闪电侠,《跟闪电侠学 Netty》已出版了。书的前半部分是掘金小册中的内容:通过一个完整的 IM 项目入门 Netty;后半部分用了较大的篇幅来介绍 Netty 的底层原理,也会穿插讲一些源码阅读的思路,希望能够帮助到你。
13篇文章21865阅读量