我爱娃哈哈的专栏

如果没有外力的作用，那么死锁涉及的各个线程都将永久处于循环等待状态，导致业务无法预期运行，所以我们的代码要避免死锁的情况。接下来我们输入 thread -b 命令查看当前阻塞其他线程的线程，然后我们可以看到 Lock 1 被阻塞了，访问的资源被 Lock 2 占用，如图所示，根据提示的行数我们便能找到死锁位置，对代码进行优化。前面我们通过JVM线程分析及内存分析来让大家从服务器资源异常情况下排查代码问题，类似这种的解决方式，更多的是在服务器资源占用已经异常显现，我们就可以按照这种方式去排查和解决。

我们先来看一下以往单体的Web系统架构图是什么样的：从图中可以看出，早期的单体架构基本上是以业务为导向，同时用户群体不是很大，这种单体的架构基本上可以应付大多数使用场景。但随着互联网的推广，用户体量的迅速攀升，响应要求的不断提高，单体架构的系统往往会频繁的出现请求延迟、响应超时或是系统宕机。特别是在数据库层面，更是无法满足高访问量的读写。为什么会产生这种情况呢？由于数据库的数据是存在硬盘上，硬盘的 I/O 读写瓶颈会直接影响并发量。

这样的报警方式更适合高级别的报警提醒，用于处理紧急情况。出现级别不高而又频繁地发送短信会让人产生排斥感，而且电话或者短信的报警方式也存在一定的成本。

如果服务器上没有应用还会造成硬件瓶颈吗？显然是不会的，。而寻找系统问题的根因，对于系统链路监控也是必不可少的，前面我们也写了几篇关于SkyWalking搭建的文章，但是文章视角不一样。之前是以架构设计的角度来通过监控体系搭建，及时了解系统的运行情况和服务器的调用链路。本篇文章主要是以测试的角度来描述搭建目的。