This repository was archived by the owner on Jan 4, 2020. It is now read-only.
修复高并发下Runtime的一个死锁Bug #414
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
这个Bug只有在并发量很大的时候才会产生。
我们在实际中遇到了这个Bug,通过Core dump跟踪系统调用定位到了这个Bug。
这里列举一个可能产生的情况:
线程A来访的时候,如果处于Debug开启或者找不到Runtime的状态,会进入编译Runtime的分支,但是编译分支的最开始首先就把老的Runtime删除了。然后进行后续操作。此时,如果刚好又出现了一个线程B,在线程A还在构建Runtime的过程中,访问到服务器,找不到Runtime文件,此时线程B正准备进入构建Runtime的分支,而此时如果恰巧线程A刚好已经执行完了构建Runtime的操作,保存Runtime到文件中,而此时线程B要恰巧开始执行删除文件指令了,这是刚创建好的文件就被删掉了,此时线程B又会会继续创建Runtime,假设此时来了一个线程C,又会进入这样的循环。
这个Bug需要来访特别密集,否则也不容易触发,修改方案就和我代码中呈现的一样,取消else后的第一个文件删除应该就可以了。