Skip to content
This repository was archived by the owner on Jan 4, 2020. It is now read-only.

Conversation

@dajyaretakuya
Copy link
Contributor

这个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后的第一个文件删除应该就可以了。

这个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后的第一个文件删除应该就可以了。
@dajyaretakuya
Copy link
Contributor Author

补充说明一下,这个死锁的竞争条件就是:多线程条件下,对资源Runtime.php没有加锁。其实按照我提供的解决方案应该不能彻底解决问题,还需要一个锁机制。其实3.1的处理方法不错,始终不会有删除文件的操作,开发者手动删除Runtime后才会触发重建操作,这样就避免了删除文件的竞争条件了。

@liu21st liu21st merged commit da6ff8a into top-think:master Apr 18, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants