你應(yīng)該已經(jīng)發(fā)現(xiàn)大部分使用Boost.Asio編寫的代碼都會使用幾個io_service的實例。io_service是這個庫里面最重要的類；它負(fù)責(zé)和操作系統(tǒng)打交道，等待所有異步操作的結(jié)束，然后為每一個異步操作調(diào)用其完成處理程序。
? ? ? ?如果你選擇用同步的方式來創(chuàng)建你的應(yīng)用，你則不需要考慮我將在這一節(jié)向你展示的東西。 你有多種不同的方式來使用io_service。在下面的例子中，我們有3個異步操作，2個socket連接操作和一個計時器等待操作：
1.單線程：一個io_service實例和一個處理線程

io_service?service;?//?所有socket操作都由service來處理
ip::tcp::socket?sock1(service);
ip::tcp::socket?sock2(service);
sock1.async_connect(?ep,?connect_handler);
sock2.async_connect(?ep,?connect_handler);
deadline_timer?t(service,?boost::posixtime::seconds(5));
t.async_wait(timeout_handler);
service.run();

2.多線程：一個io_server實例和多個處理線程

io_service?service;
ip::tcp::socket?sock1(service);
ip::tcp::socket?sock2(service);
sock1.async_connect(?ep,?connect_handler);
sock2.async_connect(?ep,?connect_handler);
deadline_timer?t(service,?boost::posixtime::seconds(5));
t.async_wait(timeout_handler);
for?(?int?i?=?0;?i?<?2;?++i)
????boost::thread(run_service);
void?run_service()
{
????service.run();
}

3.多線程：多個io_service實例和多個線程

io_service?service[2];
ip::tcp::socket?sock1(service[0]);
ip::tcp::socket?sock2(service[1]);
sock1.async_connect(?ep,?connect_handler);
sock2.async_connect(?ep,?connect_handler);
deadline_timer?t(service[0],?boost::posixtime::seconds(5));
t.async_wait(timeout_handler);
for?(?int?i?=?0;?i?<?2;?++i)
????boost::thread(?boost::bind(run_service,?i));
void?run_service(int?idx)
{
????service[idx].run();
}

? ? ? ?首先，要注意你不能擁有多個io_service實例卻只有一個線程。下面的代碼片段沒有任何意義：

for?(?int?i?=?0;?i?<?2;?++i)
????service[i].run();

? ? ? ?上面的代碼片段沒有意義是因為service[1].run()需要service[0].run()先結(jié)束。因此，所有由service[1]處理的異步操作都需要等待，這顯然不是一個好主意。
? ? ? ?在前面的3個方案中，我們在等待3個異步操作結(jié)束。為了解釋它們之間的不同點，我們假設(shè)：過一會操作1完成，然后接著操作2完成。同時我們假設(shè)每一個完成處理程序需要1秒鐘來完成執(zhí)行。
? ? ? ?在第一個例子中，我們在一個線程中等待三個操作全部完成，第1個操作一完成，我們就調(diào)用它的完成處理程序。盡管操作2緊接著完成了，但是操作2的完成處理程序需要在1秒鐘后，也就是操作1的完成處理程序完成時才會被調(diào)用。
? ? ? ?在第二個例子中，我們在兩個線程中等待3個異步操作結(jié)束。當(dāng)操作1完成時，我們在第1個線程中調(diào)用它的完成處理程序。當(dāng)操作2完成時，我們立即在第2個線程中調(diào)用它的完成處理程序（當(dāng)線程1在忙著響應(yīng)操作1的處理程序時，線程2可以自由處理任何新進來的操作）。
? ? ? ?在第三個例子中，因為操作1是sock1的connect，操作2是sock2的connect，所以應(yīng)用程序會表現(xiàn)得像第二個例子一樣。線程1會處理sock1 connect操作的完成處理程序，線程2會處理sock2 connect操作的完成處理程序。然而，如果sock1的connect操作是操作1，deadline_timer t的超時操作是操作2，線程1將最終處理sock1 connect操作的完成處理程序。因此，deadline_timer t的超時操作必須等sock1 connect操作的完成處理程序結(jié)束（等待1秒鐘），因為線程1要順序處理sock1的連接處理程序和t的超時處理程序。
下面是你需要從前面的例子中學(xué)到的：
1.方案一適合非常基礎(chǔ)的應(yīng)用。因為是串行的方式，所以當(dāng)幾個處理程序需要被同時調(diào)用時，你通常會遇到瓶頸。如果一個處理程序需要花費很長的時間來執(zhí)行，所有隨后的處理程序都不得不等待。
2.方案二適合大多數(shù)應(yīng)用。他是非常健壯的——如果幾個處理程序被同時調(diào)用了（這是有可能的），它們會在各自的線程里面被調(diào)用。唯一的瓶頸就是所有的處理線程都很忙的同時又有新的處理程序被調(diào)用。然而，這是有快速的解決方式的，增加處理線程的數(shù)目即可。
3.方案三四最復(fù)雜也是最靈活的。你只有在第二種情況不能滿足需求時才使用它。這種情況一般就是當(dāng)你有成千上萬并發(fā)（socket）連接時。你可以認(rèn)為每一個處理線程（運行io_service::run()的線程）有它自己的select/epoll循環(huán)；它等待任意一個socket連接，然后監(jiān)聽一個讀寫操作，當(dāng)它發(fā)現(xiàn)這種操作時，就執(zhí)行。大部分情況下，你不需要擔(dān)心什么，唯一你需要擔(dān)心的就是當(dāng)你監(jiān)聽的socket數(shù)目以指數(shù)級的方式增長時（超過1000個socket）。在那種情況下，有多個select/epoll循環(huán)會增加應(yīng)用的響應(yīng)時間。
? ? ? ?如果你覺得你的應(yīng)用程序可能需要轉(zhuǎn)換到第三種模式，請確保監(jiān)聽操作的這段代碼（調(diào)用io_service::run()的代碼）和應(yīng)用程序其他部分是隔離的，這樣你就可以很輕松地對其進行更改。
? ? ? ?最后，需要一直記住的是如果沒有其他需要監(jiān)控的操作，run()就會結(jié)束，就像下面的代碼片段：

io_service?service;
tcp::socket?sock(service);
sock.async_connect(?ep,?connect_handler);
service.run();

? ? ? ?在上面的例子中，只要sock建立了一個連接，connect_handler就會被調(diào)用，然后接著service.run()就會完成執(zhí)行。
? ? ? ?如果你想要service.run()接著執(zhí)行，你需要分配更多的工作給它。這里有兩個方式來完成這個目標(biāo)。一種方式是在connect_handler中啟動另外一個異步操作來分配更多的工作。 另一種方式會模擬一些工作給它，用下面的代碼片段：

typedef?boost::shared_ptr?work_ptr;
work_ptr?dummy_work(new?io_service::work(service));

? ? ? 上面的代碼可以保證service.run()一直運行直到你調(diào)用service.stop()或者dummy_work.reset(0);// 銷毀 dummy_work.