两起“蝴蝶效应”Cases

最近碰到了两个case,一个是一个系统变慢了一点,招致另外一个系统暴显露ThreadLocal运用不当形成的小的缺点;另外一个是一个小的边缘系统出现效果招致的严重缺点。

Case One
有一个系统突然出现频繁的cms gc,dump内存后看到主要的消耗是在ThreadLocal里的一个对象,经过排查发现主要缘由是在处置进程中有一个中央往ThreadLocal里塞了一个用来做cache的对象,但悲催的是每次会从ThreadLocal里先获取这个对象实例,然后塞一些对象到这个实例里的HashMap,而线程又是复用的,从而招致了HashMap里的对象不时的堆积,于是招致了缺点。

这个Case最诡异的是突然出现,之前不时都运转的好好的,结果发现之所以出现是由于刚好这个系统依赖的后端一个系统变慢,而变慢后招致存活的线程变多,ThreadLocal里堆积的这些对象累积占用的内存也就变多了,刚好变多了后把原本剩余的那点内存给耗光了,所以频繁cms gc。

还有一种在线程复用下错误用ThreadLocal的方式是每次new ThreadLocal,在线程复用的状况下这会招致堆积很多的ThreadLocal对象,异样很容易招致内存用满。

所以通常我们都建议要慎重运用ThreadLocal,能不用最好是别用。

Case Two
一个超级重要的系统,突然出现vip挂掉,招致外部用户全部访问不到,在排查时突然又恢复了。

继续排查时,首先发现vip做安康反省时失败,对应的vip下的机器的访问日志里看到前往的http形状码是499,依照之前的阅历,前往499都是由于后端处置慢招致的,而安康反省的文件是个静态文件,没任何逻辑,所以要形成这里处置慢只要一个缘由,就是http的处置线程全部被耗光了。

于是观察那个时分这个系统依赖的几个主要点的照应时间,发现没什么变化。

http处置线程全部耗光,要知道缘由最好的方法是在事先有效果的时分dump线程信息,但悲催的是事先没做dump,于是一摸黑,希冀着经过系统日志来排查,结果是排查了一圈也没发现任何效果。

还好在这个时分某同窗告知在缺点出来之前有系统不太正常的现象,于是做了线程dump,捞到这个线程dump一看,http的处置线程大局部都在发起一个http央求,等候结果前往。

和业务方同窗确认了下是什么央求,确认这只是一个页面发起的异步央求,而且很不重要,但从线程dump来看有能够是这个中央的效果,于是就找人去确认事先这个url对应的系统发作了什么,结果是在那个时间点刚好这个url对应的系统做了个举措,招致没有照应,而出缺点的这个系统在发起这个http的央求时没设置超时,于是悲催了,一切处置线程被耗光,招致了vip安康反省失败。

这个缺点聚集了以前出现过的严重缺点的几个特征:
1. 一个不重要的系统出效果了招致了重要系统的缺点,这主要缘由就是隔离没做好,例如这种不重要的url的处置应该放在一个不重要的系统上去做,这样最多也就是那个不重要的系统挂掉;
2. 远程访问的超时,在高并发的系统里,任何的远程操作都必需设置超时(不过在下面的案例中仅仅设置超时是没用的,还是要靠隔离),而且超时不能设置太长(我做的效劳框架第一个版本上线时就由于默许超时时间60s招致了严重缺点)。

下面的这两起case其实都是一个系统的效果招致另外一个系统也出效果,这是互联网这类高可用性系统中最惧怕的蝴蝶效应。

提供最优质的资源集合

立即查看 了解详情