复制代码 代码如下:
# 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方法，因此可简单排除这点~~~
