首先，先了解下 php中的curl多線程函數：
# curl_multi_add_handle
# curl_multi_close
# curl_multi_exec
# curl_multi_getcontent
# curl_multi_info_read
# curl_multi_init
# curl_multi_remove_handle
# curl_multi_select
一般來說，想到要用這些函數時，目的顯然應該是要同時請求多個url，而不是一個一個依次請求，否則不如自己循環去調curl_exec好了。
步驟總結如下：
第一步：調用curl_multi_init
第二步：循環調用curl_multi_add_handle
這一步需要注意的是，curl_multi_add_handle的第二個參數是由curl_init而來的子handle。
第三步：持續調用curl_multi_exec
第四步：根據需要循環調用curl_multi_getcontent獲取結果
第五步：調用curl_multi_remove_handle，并為每個字handle調用curl_close
第六步：調用curl_multi_close
這里有一個網上找的簡單例子，其作者稱為dirty的例子，（稍后我會說明為何dirty）：
/*
Here's a quick and dirty example for curl-multi from PHP, tested on PHP 5.0.0RC1 CLI / FreeBSD 5.2.1
*/
$connomains = array(
"http://www.cnn.com/",
"http://www.canada.com/",
"http://www.yahoo.com/"
);
$mh = curl_multi_init();
foreach ($connomains as $i => $url) {
$conn[$i]=curl_init($url);
curl_setopt($conn[$i],CURLOPT_RETURNTRANSFER,1);
curl_multi_add_handle ($mh,$conn[$i]);
}
do { $n=curl_multi_exec($mh,$active); } while ($active);
foreach ($connomains as $i => $url) {
$res[$i]=curl_multi_getcontent($conn[$i]);
curl_close($conn[$i]);
}
print_r($res);
整個使用過程差不多就是這樣，但是，這個簡單代碼有個致命弱點，就是在do循環的那段，在整個url請求期間是個死循環，它會輕易導致CPU占用100%。
現在我們來改進它，這里要用到一個幾乎沒有任何文檔的函數curl_multi_select了，雖然C的curl庫對select有說明，但是，php里的接口和用法確與C中有不同。
把上面do的那段改成下面這樣：
do {
$mrc = curl_multi_exec($mh,$active);
} while ($mrc == CURLM_CALL_MULTI_PERFORM);
while ($active and $mrc == CURLM_OK) {
if (curl_multi_select($mh) != -1) {
do {
$mrc = curl_multi_exec($mh, $active);
} while ($mrc == CURLM_CALL_MULTI_PERFORM);
}
}
因為$active要等全部url數據接受完畢才變成false，所以這里用到了curl_multi_exec的返回值判斷是否還有數據，當有數據的時候就不停調用curl_multi_exec，暫時沒有數據就進入select階段，新數據一來就可以被喚醒繼續執行。這里的好處就是CPU的無謂消耗沒有了。
另外：還有一些細節的地方可能有時候要遇到：
控制每一個請求的超時時間，在curl_multi_add_handle之前通過curl_setopt去做：
curl_setopt($ch, CURLOPT_TIMEOUT, $timeout);
判斷是否超時了或者其他錯誤，在curl_multi_getcontent之前用：curl_error($conn[$i]);
這里我只是簡單使用上述的dirty的例子（足夠用了，并未發現cpu使用100%的情況）。
對“看點”（kandian.com）某一接口模擬并發，功能是向 memcache中讀數據并寫入數據。因為保密關系，相關數據及結果就不貼出了。
模擬了3次，第一次10線程同時請求1000次，第二次，100線程同時請求1000次，第三次，1000線程同時請求100次（已經相當費勁了，不敢在設置超過1000的多線程）。
看來curl多線程模擬并發還是有一定局限的。
另外還懷疑，可能會因為多線程延遲帶來結果的大誤差，對比數據發現。在初始化和set所用時間出入不大，差別處在get方法，因此可簡單排除這點~~~
