网络上比较推崇使用Spring Event 优雅的实现观察者模式，但线上的一次事故，让我意识它并没有那么好用。

你好呀，我是歪歪。 前段时间踩到一个比较无语的生产 BUG，严格来说其实也不能算是 BUG，只能说开发同事对于业务同事的需求理解没有到位。 这个 BUG 其实和分页没有任何关系，但是当我去排查问题的时

本文我们主要探究一下Full GC的角度出发分析我在开发运营后台的时候遇到的频繁Full GC过程。

0. 引言 前一段时间出现了一个正则表达式引起的线上CPU爆满的问题，一开始没有在第一时间定位到问题，这里也特此记录一下，同时也系统的梳理下CPU爆满问题的排查思路和方法，为后续的同学提供参考。 1.

本周，又一Java服务出现了内存问题，这次问题不严重，只会触发堆内存占用高报警，没有触发OOM，但好在之前的复盘中总结了dump脚本，会在堆占用高时自动执行jstack与jmap

在高并发下，Java程序的GC问题属于很典型的一类问题，带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」，GC期间都存在Stop The World问题，因此很容易导致服务超时

记一次线上容器突然cpu飙升，自己也是第一次排查这种问题大家有更好的方法可以分享一下~整个文稿是我当时排查问题的详细步骤，希望能够帮到大家

[已解决] 生产环境线程死锁造成的服务器无响应错误-线上问题定位与解决方案。代码中的线程池千万不能乱用

那么理论上，我一个线程只需要不停的执行指令，就可以跑满一个核心的利用率。 从上图可以看到，CPU利用率和上一步一样，还是所有核心100%，不过此时负载已经从11.x增加到了22.x（load average解释参考https://scoutapm.com/blog/unders…