好久没有在这里写文章了,今天心血来潮把刚写的微信消息帖上来。

前段时间公司里的程序在极少的情况下会出现“死锁”问题。其实也不能算是“前段时间”,因为这个问题时不时会出现一次,持续了一年多了吧,但由于出现次数很少,所以也一直没有动力去挖出原因来。最近由于系统变得越来越复杂,使用者也越来越多,出现的频率上升到一周一两次,于是我们也就下决心把它解决掉。

但是这个问题实在有些麻烦,它看上去像是死锁,但却无法在内存中找到“锁”的痕迹。最后阻塞的代码是在获取“读写锁”中得“读锁”,但此时的“写锁”也在当前线程手中,因此不该无法进入。

我在StackOverflow上详细地描述了这个问题,也在MVP内部邮件列表里抄送了一份,但始终没有得到有价值的回复。有意思的是,InfoQ首席.NET编辑Jonathan Allen也回答了这个问题,不过我并不同意他的看法……

我现在在想,其实StackOverflow是否适合稍微复杂一些的问题,因为这样的问题往往需要深入分析,甚至需要来回补充更多资料,但大家都很忙,对于此类问题甚至没有精力去读完它的描述。而且高手的时间都很宝贵,放在我身上也不会愿意花三个小时去解决别人的问题,我是要卖每小时1000块钱的呢。

最后我还是自己解决了这个问题,为此我几乎看遍了所有相关方法的内部实现。我把问题的原因和解决方案详细地写在了那个问题后面,还挺花了一番功夫。还好我从来不怕把一个问题讲清楚,多少年博客写下来,早就充分锻炼了表达能力。

其实这也是我在工作中经常做的事情。除了开发,我经常要想办法解决系统中的疑难杂症。我的老板有深厚的技术背景,几乎没法糊弄过去,每个问题都要解释清楚才行,因此这种大段的分析文字也经历过不知道多少次。

点击“阅读原文”可以跳转至该问题及其答案。建议您耐心阅读,要知道深入分析并解决一个问题是十分有益处的练习。最后假如您觉得有帮助,也不妨给我点个赞,谢谢。

--

欢迎关注“赵人希”公众账号。赵人希,老赵在技术娱乐圈的沉浮史。

qrcode