线程转储文件分析模式 – 交通拥堵

描述

线程-A 可能获得了锁-1,但却永远不会释放它。线程-B 可能已经获得了锁-2,并且在等待获得锁-1。线程-C 可能正在等待获取锁-2。这种线程之间的可传递阻塞会使整个应用程序进入无响应状态。看看下方的真实例子吧。

示例

下面是摘自一款大型旅行应用程序的真实示例。这里‘Finalizer’线程正在等待由‘ajp-bio-192.168.100.41-7078-exec-40’线程占据的锁。ajp-bio-192.168.100.41-7078-exec-40 及多个其他线程正在等待由‘ajp-bio-192.168.100.41-7078-exec-12’线程所占据的锁。

这样一来,‘ajp-bio-192.168.100.41-7078-exec-12’总公共导致了 42 个线程出现阻塞。这种涟漪似的效应让整个应用程序进入无响应状态。原来,‘ajp-bio-192.168.100.41-7078-exec-12’由于 APM 监控代理(Ruxit)中的 bug 陷入了永久性阻塞。将代理版本升级至最新解决了该问题。这是非常讽刺的一种情形 – APM 监控代理的目的就是预防/隔离此类阻塞问题,但在当前的情形中它却变成了导致问题的源头。就像是执法机构知法犯法一样。

图:展示线程间传递性阻塞的图表

请参考这篇文章以了解被阻塞线程的栈追踪信息。

为什么我们要将其命名为交通拥堵

交通拥堵通常会在道路前方发生事故时出现。事故会导致跟随前车的所有车辆都被堵在路上。这与上方描述的传递性阻塞行为非常相似。

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: