推薦：簡(jiǎn)單理解Web Service三種實(shí)現(xiàn)方式
Web Service概念： 根據(jù)W3C的定義，Web服務(wù)(Web service)應(yīng)當(dāng)是一個(gè)軟件系統(tǒng)，用以支持網(wǎng)絡(luò)間不同機(jī)器的互動(dòng)操作。網(wǎng)絡(luò)服務(wù)通常是許多應(yīng)用程序接口(API)所組成的，它們通過網(wǎng)絡(luò)的遠(yuǎn)程服務(wù)器端，執(zhí)行客戶所提交服務(wù)的請(qǐng)求。簡(jiǎn)單的來說就是服務(wù)器端向客戶端提供服務(wù)。 We

 　　方案一

　　這是最簡(jiǎn)單的版本，在單線程下(或者是C++0X下)是沒任何問題的，但在多線程下就不行了，因?yàn)閟tatic QMManager instance_;這句話不是線程安全的。

　　在局部作用域下的靜態(tài)變量在編譯時(shí)，編譯器會(huì)創(chuàng)建一個(gè)附加變量標(biāo)識(shí)靜態(tài)變量是否被初始化，會(huì)被編譯器變成像下面這樣(偽代碼)：

　　這里有競(jìng)爭(zhēng)條件，兩個(gè)線程同時(shí)調(diào)用instance()時(shí)，一個(gè)線程運(yùn)行到if語句進(jìn)入后還沒設(shè)constructed值，此時(shí)切換到另一線程，constructed值還是false，同樣進(jìn)入到if語句里初始化變量，兩個(gè)線程都執(zhí)行了這個(gè)單例類的初始化，就不再是單例了。

　　方案二

　　一個(gè)解決方法是加鎖：

　　但這樣每次調(diào)用instance()都要加鎖解鎖，代價(jià)略大。

　　方案三

　　那再改變一下，把內(nèi)部靜態(tài)實(shí)例變成類的靜態(tài)成員，在外部初始化，也就是在include了文件，main函數(shù)執(zhí)行前就初始化這個(gè)實(shí)例，就不會(huì)有線程重入問題了：

　　這被稱為餓漢模式，程序一加載就初始化，不管有沒有調(diào)用到。

　　看似沒問題，但還是有坑，在一個(gè)2B情況下會(huì)有問題：在這個(gè)單例類的構(gòu)造函數(shù)里調(diào)用另一個(gè)單例類的方法可能會(huì)有問題。

　　看例子：

　　這里QMManager的構(gòu)造函數(shù)調(diào)用了QMSqlite的instance函數(shù)，但此時(shí)QMSqlite::instance_可能還沒有初始化。

　　這里的執(zhí)行流程：程序開始后，在執(zhí)行main前，執(zhí)行到QMManager QMManager::instance_;這句代碼，初始化QMManager里的instance_靜態(tài)變量，調(diào)用到QMManager的構(gòu)造函數(shù)，在構(gòu)造函數(shù)里調(diào)用QMSqlite::instance()，取QMSqlite里的instance_靜態(tài)變量，但此時(shí)QMSqlite::instance_還沒初始化，問題就出現(xiàn)了。

　　那這里會(huì)crash嗎，測(cè)試結(jié)果是不會(huì)，這應(yīng)該跟編譯器有關(guān)，靜態(tài)數(shù)據(jù)區(qū)空間應(yīng)該是先被分配了，在調(diào)用QMManager構(gòu)造函數(shù)前，QMSqlite成員函數(shù)在內(nèi)存里已經(jīng)存在了，只是還未調(diào)到它的構(gòu)造函數(shù)，所以輸出是這樣：

　　QMManager constructor

　　QMSqlite do_something

　　QMSqlite constructor

　　方案四

　　那這個(gè)問題怎么解決呢，單例對(duì)象作為靜態(tài)局部變量有線程安全問題，作為類靜態(tài)全局變量在一開始初始化，有以上2B問題，那結(jié)合下上述兩種方式，可以解決這兩個(gè)問題。boost的實(shí)現(xiàn)方式是：?jiǎn)卫龑?duì)象作為靜態(tài)局部變量，但增加一個(gè)輔助類讓單例對(duì)象可以在一開始就初始化。如下：

　　結(jié)合方案3的.cpp，這下可以看到正確的輸出和調(diào)用了：

　　QMManager constructor

　　QMSqlite constructor

　　QMSqlite do_something

　　來看看這里的執(zhí)行流程：

　　初始化QMManager類全局靜態(tài)變量create_object_

　　->調(diào)用object_creator的構(gòu)造函數(shù)

　　->調(diào)用QMManager::instance()方法初始化單例

　　->執(zhí)行QMManager的構(gòu)造函數(shù)

　　->調(diào)用QMSqlite::instance()

　　->初始化局部靜態(tài)變量QMSqlite instance

　　->執(zhí)行QMSqlite的構(gòu)造函數(shù)，然后返回這個(gè)單例。

　　跟方案三的區(qū)別在于QMManager調(diào)用QMSqlite單例時(shí)，方案3是取到全局靜態(tài)變量，此時(shí)這個(gè)變量未初始化，而方案四的單例是靜態(tài)局部變量，此時(shí)調(diào)用會(huì)初始化。

　　跟最初方案一的區(qū)別是在main函數(shù)前就初始化了單例，不會(huì)有線程安全問題。

　　最終boost

　　上面為了說明清楚點(diǎn)去除了模版，實(shí)際使用是用模版，不用寫那么多重復(fù)代碼，這是boost庫的模板實(shí)現(xiàn)：

　　其實(shí)Boost庫這樣的實(shí)現(xiàn)像打了幾個(gè)補(bǔ)丁，用了一些奇技淫巧，雖然確實(shí)繞過了坑實(shí)現(xiàn)了需求，但感覺挺不好的。

分享：Asp.net中Ajax與JQuery的ready函數(shù)沖突怎么辦
Asp.net Ajax和Asp.net結(jié)合得很完美，發(fā)現(xiàn)不夠用的時(shí)候，難免想到了Jquery。一般Jquery和Asp.net Ajax這兩樣?xùn)|西結(jié)合使用也常見，如果處理好的話，并不會(huì)沖突。但最近發(fā)現(xiàn)Jquery的ready()函數(shù)在PostBack回來的時(shí)候，ready里執(zhí)行的動(dòng)作竟然無效了，第一印象：會(huì)不會(huì)Asp.