php中死鎖問(wèn)題剖析
導(dǎo)語(yǔ)：什么是php死鎖呢？如何看待php死鎖問(wèn)題呢？下面是小編給大家提供的php中死鎖問(wèn)題剖析，大家可以參考閱讀，更多詳情請(qǐng)關(guān)注應(yīng)屆畢業(yè)生考試網(wǎng)。
發(fā)現(xiàn)問(wèn)題
近期發(fā)現(xiàn)線(xiàn)上很多機(jī)器的磁盤(pán)空間報(bào)警， 且日志文件已經(jīng)清理，但是磁盤(pán)空間沒(méi)有釋放。通過(guò)ps aux | grep php-cgi 發(fā)現(xiàn)， 很多進(jìn)程的啟動(dòng)時(shí)間在幾天到幾周甚至幾個(gè)月之前。我們線(xiàn)上的php-cgi都有最大執(zhí)行次數(shù)的。一般在1天內(nèi)都會(huì)重啟一次。初步結(jié)論，這些cgi進(jìn)程有問(wèn)題。
通過(guò)lsof -p [pid] 發(fā)現(xiàn)， 啟動(dòng)時(shí)間很久的cgi進(jìn)程中打開(kāi)了一些日志文件句柄，并且沒(méi)有關(guān)閉。這些日志文件在文件系統(tǒng)中已經(jīng)刪除了。但是句柄沒(méi)關(guān)閉，導(dǎo)致磁盤(pán)空間沒(méi)有釋放。到此，磁盤(pán)空間異常的問(wèn)題基本確定。是由于cgi沒(méi)有關(guān)閉文件句柄造成的。
進(jìn)一步分析進(jìn)程， strace -p [pid]， 發(fā)現(xiàn)所有異常的進(jìn)程都阻塞與 fmutex 狀態(tài)。換句話(huà)所，異常的cgi進(jìn)程死鎖了。進(jìn)程死鎖導(dǎo)致打開(kāi)的文件句柄沒(méi)有關(guān)閉，所以導(dǎo)致磁盤(pán)空間異常。
為什么cgi進(jìn)程會(huì)死鎖呢？
什么是死鎖
學(xué)過(guò)操作系統(tǒng)的通同學(xué)，都了解多線(xiàn)程的概念。在多線(xiàn)程中訪(fǎng)問(wèn)公共資源，需要對(duì)資源加鎖。訪(fǎng)問(wèn)結(jié)束后，釋放鎖。如果沒(méi)有釋放鎖，那么下一個(gè)線(xiàn)程來(lái)獲取資源的時(shí)候就會(huì)永遠(yuǎn)都無(wú)法獲取資源的鎖，于是這個(gè)線(xiàn)程死鎖了。那么CGI是多線(xiàn)程的公共資源訪(fǎng)問(wèn)導(dǎo)致的死鎖嗎？ 答案是NO。
1. CGI 是單線(xiàn)程進(jìn)程，通過(guò)ps 就能看到。（進(jìn)程狀態(tài) Sl的才是多線(xiàn)程進(jìn)程）。
2. 即使是多線(xiàn)程的，死鎖發(fā)生在PHP的shutdown過(guò)程中調(diào)用glibc 中time 函數(shù)的位置，不是php模塊造成的。而glibc 中的time相關(guān)函數(shù)是線(xiàn)程安全的，不會(huì)產(chǎn)生死鎖。
那是什么導(dǎo)致的死鎖呢？
通過(guò)分析linux中死鎖產(chǎn)生的機(jī)制，發(fā)現(xiàn)除了多線(xiàn)程會(huì)產(chǎn)生死鎖外，信號(hào)處理函數(shù)同樣會(huì)產(chǎn)生死鎖。那么cgi是由于信號(hào)處理導(dǎo)致的死鎖嗎？在這之前介紹一個(gè)感念。
函數(shù)的可重入性與信號(hào)安全
函數(shù)可重入是指，無(wú)論第幾次進(jìn)入該函數(shù)，函數(shù)都能正常執(zhí)行并返回結(jié)果。那么線(xiàn)程安全函數(shù)是可重入的嗎？答案是NO。 線(xiàn)程安全函數(shù)，在第一次訪(fǎng)問(wèn)公共資源時(shí)，會(huì)獲取全局鎖。如果函數(shù)沒(méi)有執(zhí)行完成，鎖還沒(méi)釋放，此時(shí)進(jìn)程被中斷。那么在中斷處理函數(shù)中，再次訪(fǎng)問(wèn)該函數(shù)，就會(huì)產(chǎn)生死鎖。那么什么樣的函數(shù)才可以在中斷處理函數(shù)中訪(fǎng)問(wèn)呢？ 除了沒(méi)有使用全局鎖的函數(shù)，還有一些signal safe的系統(tǒng)調(diào)用可以使用。調(diào)用任何其他的非signal safe的函數(shù)都會(huì)產(chǎn)生不可預(yù)知的后果（比如 死鎖）。 詳見(jiàn) man signal。在分析死鎖的原因前，我們先看看cgi執(zhí)行的流程，分析其中有沒(méi)有產(chǎn)生死鎖的可能。
PHP-CGI的執(zhí)行流程
Glibc中的時(shí)間函數(shù)使用到了全局鎖，保證函數(shù)的線(xiàn)程安全，但沒(méi)有保證信號(hào)安全（signal safe）。經(jīng)過(guò)之前的分析，我們初步懷疑死鎖是由于PHP-CGI進(jìn)程接收到了一個(gè)信號(hào)，然后在signal handle中執(zhí)行了非signal safe的函數(shù)。主流程在中斷前，正在執(zhí)行g(shù)libc中的時(shí)間函數(shù)。在函數(shù)獲取的鎖沒(méi)釋放前，進(jìn)入中斷流程。而中斷過(guò)程中又訪(fǎng)問(wèn)了glibc中的時(shí)間函數(shù)。于是導(dǎo)致了死鎖。
PHP-CGI的執(zhí)行流程，如下圖所示：
進(jìn)一步分析發(fā)現(xiàn)，所有死鎖的cgi進(jìn)程的sapi_global中都記錄了一個(gè)錯(cuò)誤信息
“Max execution timeout of 60 seconds exceeded”.
60s 是我們php-cgi中設(shè)置執(zhí)行超時(shí)。所以我們確認(rèn)了，cig在執(zhí)行過(guò)程中的確產(chǎn)生了超時(shí)異常，然后由于longjmp進(jìn)入了shutdown過(guò)程。在shutdown過(guò)程中訪(fǎng)問(wèn)了glibc中的時(shí)間函數(shù)。導(dǎo)致了死鎖。
void zend_set_timeout(long seconds)
{
TSRMLS_FETCH();
EG(timeout_seconds) = seconds;
if(!seconds) {
return;
}
……
setitimer(ITIMER_PROF, &t_r, NULL);
signal(SIGPROF, zend_timeout); /pic/p>
sigemptyset(&sigset);
sigaddset(&sigset, SIGPROF);
……
}
通過(guò)gdb調(diào)試發(fā)現(xiàn)，所有PHP-CGI都阻塞在zend_request_shutdown中。zend_request_shutdown會(huì)調(diào)用用戶(hù)自定義的php腳本中實(shí)現(xiàn)的shutdown函數(shù)。如果CGI執(zhí)行超市，那么定時(shí)器會(huì)產(chǎn)生SIGPROF信號(hào)使執(zhí)行流程中斷。如果此時(shí)腳本剛好處于調(diào)用時(shí)間函數(shù)的狀態(tài)，且還沒(méi)有釋放鎖資源。然后執(zhí)行流程進(jìn)入了 timeout 函數(shù)，繼續(xù)跳轉(zhuǎn)到zend_request_shutdown。此時(shí)如果自定義的shutdown函數(shù)中訪(fǎng)問(wèn)了時(shí)間函數(shù)。就會(huì)產(chǎn)生死鎖。我們從代碼中找到了證據(jù)：
register_shutdown_function ('SimpleWebSvc:: shutdown’);
我們?cè)趐hp代碼中使用qalarm系統(tǒng)，qalarm系統(tǒng)會(huì)在cgi執(zhí)行結(jié)束（shutdown）的時(shí)候，注入一個(gè)鉤子函數(shù)，來(lái)分析cgi執(zhí)行是否正常，如果不正常，則發(fā)送報(bào)警信息。而剛好qalarm的報(bào)警處理函數(shù)中訪(fǎng)問(wèn)了時(shí)間函數(shù)。于是就有一定的概率產(chǎn)生死鎖。
結(jié)論
通過(guò)上面的分析，我們找到了cgi死鎖產(chǎn)生的原因，是應(yīng)為在signal handler中使用了非signal safe的函數(shù)，導(dǎo)致了死鎖。
解決辦法
去掉或簡(jiǎn)化qalarm注冊(cè)到shutdown中的鉤子函數(shù)。避免不安全的函數(shù)調(diào)用。
【php中死鎖問(wèn)題剖析】相關(guān)文章：
PHP 死鎖問(wèn)題分析08-24
PHP解決session死鎖的解決方法01-26
PHP中浮點(diǎn)數(shù)的計(jì)算問(wèn)題11-17