在傳統模式C/S模式的應用程序中，通常情況下存在這樣的問題：客戶端請求服務端之后，服務端并不是馬上對處理客戶端請求時需要的資源進行釋放，服務端往往自作多情的認為客戶端一定是個老主顧，會時不時來消費一番。可他卻沒想到，有的時候，客戶端是個昧良心的家伙，就算服務端再怎么獻殷勤，客戶端也不買賬。而對于一些非常珍貴的資源，比如數據庫連接，文件，圖像，通訊端口等。服務這種做法往往會使這些資源長期被不來消費的客戶端空閑占用，當有新的請求真正要用使用他們的時候，卻因為資源耗盡而無法處理。這樣對服務端就得不償失了，而PerCall就是對上面提到問題的一種解決方案。它采用類似快餐式的經營方式，當一個請求操作來到的時候，再創建服務對象，申請必要資源，而當操作完畢之后，立即銷毀對象并釋放資源，留給下一個請求。這就可能大大提高服務端的吞吐能力。而且WCF中默認的實例創建模式就是這種。

PerSession

正如上面對PerCall的描述所說，PerSession與傳統的C/S模式應用程序非常相似，它能在服務端和客戶端維護狀態，當一個服務對象創建之后不會馬上銷毀，而是等待客戶端再次來消費它，那這種的壞處也說過了，可能會浪費寶貴的服務資源，可它也是有好處的。比如它能夠保持連接和維護狀態，這在要求有回調的情況下特別重要，因為如果服務端連哪個家伙點的菜都忘記了怎么為客人上菜呢？還有一種情況，服務端操作不需要比較多的資源或者占用的資源也不寶貴的情況下，而卻與客戶端在不同的網絡中，它們之間進行一次連接可費了老勁，這時也適用于此種實例模式。

Single

大家經常去理發吧？去那大的理發店，里面的理發師這家伙這個多，你隨便找個就能幫你料理了，可兄弟我比較窮酸，每次都去小區理發店，里面連洗頭，在理發就1位師傅，小區人可不少，僧多飯少，你說咱進去得排隊吧。人家理發的時候，咱就得邊上看著，得人家都整完了，嘿，咱就洗頭，理發，吹風來個一條龍。Single模式就像上面提到的小區理發店，人家從早晨一開業，理發師就給你準備好了，您也甭挑蹦撿。伺候完你，他再伺候別人，為何要這么做？其實道理也很簡單，如果理發師不喝水，不吃飯，不用管食宿，不用工錢，不會唧唧歪歪，那理發店老板娘肯定請1萬個過來。可現實不是那樣子的，是這些理發師都要吃喝拉撒睡，還要拿俸祿，就一個幾十平米的小理發店，估計給老板娘賣了也不夠他們的呢。

使用不同的實例模式，需要注意的有哪些？

對于PerCall模式，一定要記住，如果服務對象中的數據沒有固化，并且不是靜態變量，那它每次操作都會被重新初始化。
對于PerSession模式,第一要清楚有些Binding是不能用于此種模式的，具體什么可用，什么不能用，可以查閱http://www.cnblogs.com/jillzhang/archive/2008/02/03/1063406.html 。另外，PerSession模式并不是代表狀態會自動維護，那些被設置了IsTerminating=True的操作完成的時候，也會釋放資源和銷毀對象。即使不是Ture，那如果客戶端長時間不與服務端聯系，達到服務端最大忍耐限度，服務端也會變心。
對于Single模式，既然例外就它老哥一個，就簡單得多了，它能保持服務對象中的非靜態全局變量。但是特別要注意的是，如果在這種模式下的話，要特別注意線程安全的問題，讓10個人同時讓一個理發師傅來服務。

代碼不騙人，用一個小范例來看看不同實例模式的區別？

寫了一個簡單的范例，來驗證和說明上述的觀點，下面就先看一下最后的運行效果：

服務端運行效果解圖：