YGC问题排查,又让我涨姿势了!
在高并发下,Java程序的GC问题属于很典型的一类问题,带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」,由于GC期间都存在Stop The World问题,因此很容易导致服务
线程池运用不当的一次线上事故
在高并发、异步化等场景,线程池的运用可以说无处不在。线程池从本质上来讲,即通过空间换取时间,因为线程的创建和销毁都是要消耗资源和时间的,对于大量使用线程的场景,使用池化管理可以延迟线程的销毁,大大提高
JVM 源码分析之一个 Java 进程究竟能创建多少线程
概述虽然这篇文章的标题打着JVM源码分析的旗号,不过本文不仅仅从 JVM 源码角度来分析,更多的来自于 Linux Kernel 的源码分析,今天要说的是 JVM 里比较常见的一个问题。这个问题可能有
记一次Synchronized关键字使用不合理,导致的多线程下线程阻塞问题排查
在为客户进行性能诊断调优时,碰到了一个Synchronized关键字使用不合理导致多线程下线程阻塞的情况。用文字记录下了问题的整个发现-排查-分析-优化过程,排查过程中使用了我司商业化产品——XLan
一次 Java 进程 OOM 的排查分析(glibc 篇)
遇到了一个 glibc 导致的内存回收问题,查找原因和实验的的过程是比较有意思的,主要会涉及到下面这些:- Linux 中典型的大量 64M 内存区域问题- glibc 的内存分配器 ptmalloc
官方文档竟然有坑!关于G1参数InitiatingHeapOccupancyPercent的正确认知 #我在性能调优路上的打怪日记#
问题前两天,一个群友在群中提出一个疑问:G1里的XX:InitiatingHeapOccupancyPercent,默认是45。他看网上有两种说法,一种是整个堆占用率超过45%时开始并发标记周期;另一
记一次类加载失败导致线程阻塞问题排查
作为PerfMa解决方案管理部门的技术专家,我在工作遇见过很多各种问题导致的性能问题,并参与了为客户的系统进行性能诊断调优的全过程。这一次碰到了一个类加载失败导致的性能问题。用文字记录下了问题的整个发
你确定你真的理解"双亲委派"了吗?!
最近一段时间,我在面试的过程中,很喜欢问双亲委派的一些问题,因为我发现这个问题真的可以帮助我全方位的了解一个候选人。记得前几天一次面试过程中,我和一位候选人聊到了JVM的类加载机制的问题,他谈到了双亲
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
据说99.99%的人都会答错的类加载的问题
概述首先还是把问题抛给大家,这个问题也是我厂同学在做一个性能分析产品的时候碰到的一个问题。 同一个类加载器对象是否可以加载同一个类文件多次并且得到多个Class对象而都可以被java层使用吗请仔细注意
高吞吐、低延迟 Java 应用的 GC 优化实践
本篇原文作者是 LinkedIn 的 Swapnil Ghike,这篇文章讲述了 LinkedIn 的 Feed 产品的 GC 优化过程,虽然文章写作于 April 8, 2014,但其中的很多内容和
跟Kafka学技术系列之时间轮
kafka的延迟队列使用时间轮实现,能够支持大量任务的高效触发,但是在kafka延迟队列实现方案里还是看到了delayQueue的影子,使用delayQueue是对时间轮里面的bucket放入延迟队列,以此来推动时间轮滚动,但是基于将插入和删除操作则放入时间轮中,将这些操作的时间复杂度都降为O(1)
Java语言
消失的死锁
问题描述如果java层面发生了死锁,当我们使用jstack命令的时候其实是可以将死锁的信息给dump出来的,在dump结果的最后会有类似Found one Java-level deadlock:的关
在调试器里看LINUX内核态栈溢出
图灵最先发明了栈,但没有给它取名字。德国人鲍尔也“发明”了栈,取名叫酒窖。澳大利亚人汉布林也“发明”了栈,取名叫弹夹。1959年,戴克斯特拉在度假时想到了Stack这个名字,后来被广泛使用。
性能优化:线程资源回收
一、问题模型服务平台的排序请求出现较多超时情况,且不定时伴随空指针异常。 二、问题发生前后的改动召回引擎扩大了召回量,导致排序请求的item数量增加了。 三、出问题的模型基于XGBoost预测的全排序
JVM源码分析之jstat工具原理完全解读
概述jstat是hotspot自带的工具,和java一样也位于`JAVA_HOME/bin`下面,我们通过该工具可以实时了解当前进程的gc,compiler,class,memory等相关的情况,具体
Java Reference核心原理分析
带着问题,看源码针对性会更强一点、印象会更深刻、并且效果也会更好。所以我先卖个关子,提两个问题(没准下次跳槽时就被问到)。 - 我们可以用ByteBuffer的allocateDirect方法,申请一
一次线上服务高 CPU 占用优化实践
线上有一个非常繁忙的服务的 JVM 进程 CPU 经常跑到 100% 以上,下面写了一下排查的过程。通过阅读这篇文章你会了解到下面这些知识。- Java 程序 CPU 占用高的排查思路- 可能造成线上
死磕一道面试题引发的对Java内存模型的一点疑问,第四部。
死磕一道面试题引发的对Java内存模型的一点疑问,JIT在将热点代码编译成机器码的时候就是单纯的不喜欢成员字段或者静态字段。或者说为了提高代码执行效率,只是这种意义一般人看不出来,需要从CPU执行指令的角度才能明白。虽然优化前和优化后这俩个变量hoistedStopRequested和stopReq
代表Java未来的ZGC深度剖析,牛逼!
JAVA程序最爽的地方是它的GC机制,开发人员不需要关注内存申请和回收问题。同时,JAVA程序最头疼的地方也是它的GC机制,因为掌握JVM和GC调优是一件非常困难的事情。在ParallelOldGC、
警惕大量类加载器的创建导致诡异的Full GC
概述 今天有个同事找我,其实好像之前就找过我,一直因为太忙,后面就忘记他的事了,到今天还没查出原因就又找了过来,现象是系统老是进行Full GC,在启动没过多久就会发生Full GC,这个现象相
Java8 Stream源码分析
Stream Stream是在Java SE 8 API添加的用于增强集合的操作接口,可以让你以一种声明的方式处理集合数据。将要处理的集合看作一种流的创建者,将集合内部的元素转换为流并且在管道中传
一次线上JVM调优实践,FullGC40次/天到10天一次的优化过程
通过这一个多月的努力,将FullGC从40次/天优化到近10天才触发一次,而且YoungGC的时间也减少了一半以上,这么大的优化,有必要记录一下中间的调优过程。对于JVM垃圾回收,之前一直都是处于理论
谨防JDK8重复类定义造成的内存泄漏
概述 如今JDK8成了主流,大家都紧锣密鼓地进行着升级,享受着JDK8带来的各种便利,然而有时候升级并没有那么顺利?比如说今天要说的这个问题。我们都知道JDK8在内存模型上最大的改变是,放弃了Perm
为你总结了N个真实线上故障,从容应对面试官!
很多人在面试时,会被问到这样的问题:遇到过什么系统故障?怎么解决的?下面是笔者根据自己15年互联网研发经历总结的多个线上故障真实案例。相信可以帮你从容应对面试官的提问!本文图不多,但内容很干!理解为主
实战:OOM 后我如何分析解决的
现在很多面试官都会关心你是否有过解决内存泄漏的问题,是否有过JVM的调优经验。你如果没有经历过,该如何回答呢?希望下文对你有所帮助。 背景前不久,上线了一个新项目,这个项目是一个压测系统,可以简单的看
分析和解决JAVA 内存泄露的实战例子
这几天,一直在为Java的“内存泄露”问题纠结。Java应用程序占用的内存在不断的、有规律的上涨,最终超过了监控阈值。福尔摩 斯不得不出手了! 分析内存泄露的一般步骤 如果发现Java应用程序占用的内
不可逆的类初始化过程
类的加载过程说复杂很复杂,说简单也简单,说复杂是因为细节很多,比如说今天要说的这个,可能很多人都不了解;说简单,大致都知道类加载有这么几个阶段,loaded-linked-initialized,为了
记一次JVM堆外内存泄露Bug的查找
前言JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存,同时对物理内存的使用做了定量的分析,从而实锤了Bug的源头。笔者将此Bug分析的过程写成博客,以飨
改善 Kubernetes 上的 JVM 预热问题
JVM 预热是一个非常头疼而又难解决的问题。本文讨论了在运行在 Kubernetes 集群中的 Java 服务如何解决 JVM 预热问题的一些方法和经验。 作者:Vikas Kumar 翻译:Bach
JDK的sql设计不合理导致的驱动类初始化死锁问题
问题描述当我们一个系统既需要mysql驱动,也需要oracle驱动的时候,在并发加载初始化这些驱动类的过程中产生死锁的可能性非常大,下面是一个模拟的例子,对于Thread2的实现其实是jdk里java
记录一次Flink作业异常的排查过程
最近2周开始接手apache flink全链路监控数据的作业,包括指标统计,业务规则匹配等逻辑,计算结果实时写入elasticsearch. 昨天遇到生产环境有作业无法正常重启的问题,我负责对这个问题
JVM Metaspace内存溢出排查与总结
现象前段时间公司线上环境的一个Java应用因为OOM的异常报警,导致整个服务不可用被拉出集群,本地模拟重现的现象如下:当时的解决方案是增加metaspace的容量:-XX:MaxMetaspaceSi
OutOfMemoryError之unable to create new native thread原因分析及6种解决方案
java.lang.OutOfMemoryError:unable to create new native thread 是比较常见的一种异常,表示应用程序无法创建新的线程。产生该异常,总体上可总结
JVM Code Cache空间不足,导致服务性能变慢
有业务反馈,线上一个应用运行了一段时间之后,在高峰期之后,突然发现处理能力下降,接口的响应时间变长,但是看Cat上的GC数据,一切都很正常。通过跳板机上机器查看日志,发现一段平时很少见到的日志:```
用crash工具分析Linux内核死锁的一次实战
背景知识点ramdump是内存转存机制,我们可以在某个时刻把系统的内存转存到一个文件中,然后与符号信息(vmlinux)一起导入到trace32或crash等内存分析工具中做离线分析。是分析崩溃、死锁
Kafka 顺序消费线程模型的实践与优化
各类消息中间件对顺序消息实现的做法是将具有顺序性的一类消息发往相同的主题分区中,只需要将这类消息设置相同的 Key 即可,而 Kafka 会在任意时刻保证一个消费组同时只能有一个消费者监听消费,因此可
JDK ThreadLocal 源码深度剖析及注意点分享
概述 ```ThreadLocal``` 顾名思义,就是“线程局部”的意思,换句话说就是属于某个线程的局部对象,其他线程是没法访问到的,亦即该对象不存在线程安全的问题,因为不可能被多线程访问到,
AsyncGetCallTrace 源码深度剖析
前言 AsyncGetCallTrace 是由 OracleJDK/OpenJDK 内部提供的一个函数,该函数可以在 JVM 未进入 safepoint 时正常获取到当前线程的调用栈(换句话说,使用
Java多线程——并发测试
编写并发程序时候,可以采取和串行程序相同的编程方式。唯一的难点在于,并发程序存在不确定性,这种不确定性会令程序出错的地方远比串行程序多,出现的方式也没有固定规则。那么如何在测试中,尽可能的暴露出这些问
又抓了一个导致频繁GC的鬼--数组动态扩容
概述 本周有个同事过来咨询一个比较诡异的gc问题,大概现象是,系统一直在做cms gc,但是老生代一直不降下去,但是执行一次jmap -histo:live之后,也就是主动触发一次full gc之后
JAVA线上故障排查套路
线上故障主要会包括cpu、磁盘、内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的,基
使用Go语言实现Attach到目标JVM进程
0x00 Java Attach API的基本使用在JVM运行时加载一个Agent的jar包是Java agent的一种更加灵活的实现方式,因为动态Attach时不需要停止目标JVM进程,这个特性给J
XPocket插件jstack_x助力线程问题排查
在程序开发过程中,开发人员通常会遇到许多线上问题,这些问题可能是代码Bug导致的,也可能是性能问题引起的。这些线上问题都会通过CPU飙升、GC频繁、抛出OOM异常等情况表现出来,这些问题的根因很可能是
使用NMT和pmap解决JVM资源泄漏问题
编者按:笔者使用JDK自带的内存跟踪工具NMT和Linux自带的pmap解决了一个非常典型的资源泄漏问题。这个资源泄漏是由于Java程序员不正确的使用Java API导致的,使用Files.list打
Java OOM 高级篇:体验了一把线上CPU100%及应用OOM的排查和解决过程
问题现象 【告警通知-应用异常告警】简单看下告警的信息:拒绝连接,反正就是服务有问题了,请不要太在意马赛克。 环境说明Spring Cloud F版。项目中默认使用 spring-cloud-sleu
一次 JVM 进程退出分析
最近我们在测试把 APM 平台迁移到 ES APM,有同学反馈了一个有意思的现象,部署在 docker 中 jar 包项目,在新版 APM 里进程启动完就退出了,被 k8s 中无限重启。这篇文章写了一
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
一次线上 xxl-job 服务异常排查分析
问题描述某天收到频繁的告警邮件,定时任务调度失败,查看 xxl-job 的执行器列表是空的,但是服务又显示健康,查看历史任务执行记录发现执行器是依次递减,由于是线上服务,只能先重启,然后线程日志也没有
没想到,这么简单的线程池用法,深藏这么多坑
又又又踩坑了生产有个对账系统,每天需要从渠道端下载对账文件,然后开始日终对账。这个系统已经运行了很久,前两天突然收到短信预警,没有获取渠道端对账文件。本以为又是渠道端搞事情,上去一排查才发现,所有下载
一次 Spring 无法启动的问题排查(字节码篇)
一次 Spring 无法启动的原因排查,带你抽丝剥茧,看看字节码在问题分析上的应用、Kotlin 编译器、Spring 源码.
类初始化导致死锁
一张图简单描述死锁 如上图,Thread1 拿到了 object1,Thread2 拿到了 object2,但是现在 Thread1 需要拿到 object2 的锁才能继续往下,Thread2 又要拿到 object1 才能继续往下
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开发手册》是阿里巴巴集团技术团队的集体智慧结晶和经验总结,经历了多次大规模一线实战的检验及不断完善,公开到业界后,众多社区开发者踊跃参与,共同打磨完善,系统化地整理成册。会当凌绝顶,一览众山
Java 应用性能调优的一些实践
Java 应用性能优化是一个老生常谈的话题,典型的性能问题如页面响应慢、接口超时,服务器负载高、并发数低,数据库频繁死锁等。尤其是在“糙快猛”的互联网开发模式大行其道的今天,随着系统访问量的日益增加和
一次真实的线上OOM问题定位
概述近日,负责的一系统生产环境上出现了OutOfMemoryError,伴随着这个问题随之而来的是一堆Full GC, CPU 百分之百,频繁宕机重启等问题,严重影响业务的推广及使用,此类问题一般处理
垃圾回收-实战篇
JVM 参数简介在开始实践之前我们有必要先简单了解一下 JVM 参数配置,因为本文之后的实验中提到的 JVM 中的栈,堆大小,使用的垃圾收集器等都需要通过 JVM 参数来设置先来看下如何运行一个 Ja
Linux多线程应用性能分析
如今CPU的核心数越来越多, 在2019年你可以轻易买到超过50个核心的x86服务器CPU,一个中端台式机拥有8个执行线程也没什么好奇怪的。问题是我们怎样找到工作负载来“喂饱”那些相对饥饿的核。到目前
JVM源码分析之JDK8下的僵尸(无法回收)类加载器
概述这篇文章基于最近在排查的一个问题,花了我们团队不少时间来排查这个问题,现象是有一些类加载器是作为key放到WeakHashMap里的,但是经历过多次full gc之后,依然坚挺地存在内存里,但是从
高并发下的 AtomicLong 性能有点差!
如果让你实现一个计数器,有点经验的同学可以很快的想到使用AtomicInteger或者AtomicLong进行简单的封装。因为计数器操作涉及到内存的可见性和线程之间的竞争,而Atomic的实现完美的屏
一次I/O问题引发的P0重大故障
这是前段时间发的一篇文章,很多读者反馈,文章没有揭示故障发生的详细原因。本次在文中加上故障的具体原因(下面黑体字部分),再推一次。几年前的一个下午,公司里码农们正在安静地敲着代码,突然很多人的手机同时
进程物理内存远大于Xmx的问题分析
问题描述最近经常被问到一个问题,”为什么我们系统进程占用的物理内存(Res/Rss)会远远大于设置的Xmx值”,比如Xmx设置1.7G,但是top看到的Res的值却达到了3.0G,随着进程的运行,Re
不改一行代码定位线上性能问题
背景最近时运不佳,几乎天天被线上问题骚扰。前几天刚解决了一个 [HashSet 的并发问题](https://heapdump.cn/article/543424),周六又来了一个性能问题。大
分享一个Flink checkpoint失败的问题和解决办法
接触Flink一段时间了,遇到了一些问题,其中有一个checkpoint失败导致作业重启的问题,遇到了很多次,重启之后一般也能恢复正常,没有太在意,最近2天有同事又频繁遇到,这里记录一下解决方案和分析
一次“内存泄漏”引发的血案
对性能不佳的Ark Server进行了改造和重写。重编发布一段时间后,结果发现新发布的Svr的机器内存一直在上涨。如下图示:观察后,第一反应是完了,一定存在内存泄露。花了3、4天时间,使用各种办法进行
Linux上TCP的几个内核参数调优
Linux作为一个强大的操作系统,提供了一系列内核参数供我们进行调优。光TCP的调优参数就有50多个。在和线上问题斗智斗勇的过程中,笔者积累了一些在内网环境应该进行调优的参数。在此分享出来,希望对大家
一次年轻代GC长暂停问题的解决与思考
问题描述公司某规则引擎系统,在每次发版启动会手动预热,预热完成当流量切进来之后会偶发的出现一次长达1-2秒的年轻代GC(流量并不大,并且LB下的每一台服务都会出现该情况)在这次长暂停之后,每一次的年轻
CPU 优化线上实战篇:Java JVM 频繁 GC的原因和排查方法
背景线上web服务器不时的出现非常卡的情况,登录服务器top命令发现服务器CPU非常的高,重启tomcat之后CPU恢复正常,半天或者一天之后又会偶现同样的问题。解决问题首先要找到问题的爆发点,对于偶
多线程之CountDownLatch的用法及原理笔记
前言-CountDownLatch是什么?CountDownLatch是具有synchronized机制的一个工具,目的是让一个或者多个线程等待,直到其他线程的一系列操作完成。CountDownLat
久等了,网传字节跳动总结的设计模式出版了!
作者:小傅哥博客:[https://bugstack.cn](https://bugstack.cn)沉淀、分享、成长,让自己和他人都能有所收获!😄 一、前言`来自延迟满足的幸福`可能你的生活里很多
又踩到Dubbo的坑,但是这次我笑不出来
前言直入主题,线上应用发现,偶发性出现如下异常日志。当然由于线上具体异常包含信息量过大,秉承让肥朝的粉丝没有难调试的代码的原则,我特意抽取了一个复现的demo放在了git,让你不在现场,一样享受到排查
记一次线上请求偶尔变慢的排查
前言最近解决了个比较棘手的问题,由于排查过程挺有意思,于是就以此为素材写出了本篇文章。 Bug现场这是一个偶发的性能问题。在每天几百万比交易请求中,平均耗时大约为300ms,但总有那么100多笔会超过
一则OOM死机故障的处理过程
OOM是Out of Memory的简写,也就是内存不足。出现该问题的原因有很多,如程序内存泄漏等。内存泄漏问题可以通过定时地终止和重启有问题的程序来发现和解决。在比较新的Linux内核版本中,有一种
Elasticsearch调优篇-慢查询分析笔记
前言- elasticsearch提供了非常灵活的搜索条件给我们使用,在使用复杂表达式的同时,如果使用不当,可能也会为我们带来了潜在的风险,因为影响查询性能的因素很多很多,这篇笔记主要记录一下慢查询可
记一次 Java 服务性能优化
背景前段时间我们的服务遇到了性能瓶颈,由于前期需求太急没有注意这方面的优化,到了要还技术债的时候就非常痛苦了。在很低的 QPS 压力下服务器 load 就能达到 10-20,CPU 使用率 60% 以
JUC之 FutureTask 源码与工作原理分析
JDK1.5 引入了Future模式,Future代表了一个异步任务的执行结果。Future模式可以理解成:主线程将待执行的任务提交给子线程执行后,可以先获取任务结果的持有者Future。然后主线程可
JVM源码分析之Attach机制实现完全解读
Attach是什么在讲这个之前,我们先来点大家都知道的东西,当我们感觉线程一直卡在某个地方,想知道卡在哪里,首先想到的是进行线程dump,而常用的命令是jstack ,我们就可以看到如下线程栈了大家是
Java多线程知识小抄集(一)
本文主要整理笔者遇到的Java多线程的相关知识点,适合速记,故命名为“小抄集”。本文没有特别重点,每一项针对一个多线程知识做一个概要性总结,也有一些会带一点例子,习题方便理解和记忆。 1.interr
别再纠结线程池大小/线程数量了,没有固定公式的
可能很多人都看到过一个线程数设置的理论:- CPU 密集型的程序 - 核心数 + 1- I/O 密集型的程序 - 核心数 2不会吧,不会吧,真的有人按照这个理论规划线程数? 线程数和CPU利用率的小
一顿操作后,FGC频率降低到原来的1/400
通过一个多月的努力,将 FullGC 从 40 次/天优化到近 10 天才触发一次,而且 YoungGC 的时间也减少了一半以上,这么大的优化,有必要记录一下中间的调优过程。对于JVM垃圾回收,之前一
JDK11现存性能bug(JDK-8221393)深度解析
这是一篇鸽了很久的博客,因为博客内容和素材早就准备差不多了,但就是一直懒得整理,今天终于下定决心终于整理出来了,这也是这个bug [JDK-8221393](https://bugs.openjdk.
一文完全理解定时器实现技术
上一篇热文《[构建企业级业务高可用的延时消息中台](https://heapdump.cn/article/641128)》引起了大家的讨论,评论里讨论除了时间轮算法外的其他高性能算法实现延迟
我的程序跑了60多小时,就是为了让你看一眼JDK的BUG导致的内存泄漏
从一个BUG说起前段时间翻到了一个 JDK 有点意思的 [BUG](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8137185),带大家一
讨论在 Linux Control Groups 中运行 Java 应用程序的暂停问题
说明本篇原文来自 LinkedIn 的 Zhenyun Zhuang,原文:Application Pauses When Running JVM Inside Linux Control Group
惊:Dubbo居然有必现StackOverflowError的Bug
说明:本文场景基于dubbo-2.5.3版本。 如果你对StackOverflowError有一定的了解,就可以知道出现这个问题的主要原因就是调用栈太深,比如常见的无限递归调用。那本文要介绍的Dub
FGC实战:坏代码导致服务频繁FGC无响应问题分析
前些日子小组内安排值班,轮流看顾我们的服务,主要做一些报警邮件处理、Bug 排查、运营 issue 处理的事。工作日还好,无论干什么都要上班的,若是轮到周末,那这一天算是毁了。不知道是公司网络广了就这
浅析Linux IO,你需要知道的底层
在开始正式的讨论前,我先抛出几个问题:- 谈到磁盘时,常说的HDD磁盘和SSD磁盘最大的区别是什么?这些差异会影响我们的系统设计吗?- 单线程写文件有点慢,那多开几个线程一起写是不是可以加速呢?- w

有开始,就会有进​步!

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

专家作者推荐

巡山小汪

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

飞哥开发内功

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

踩刀诗人

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

Brand

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

专题推荐

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