併發小工具

其實就是多執行緒構造多個請求，請求同乙個位址，在**測試的時候還是能用上的，有的時候方法在同一時間只能被乙個執行緒訪問，用這個工具就可以測試的方法是不是真的是在同一時間只能被乙個執行緒訪問，在處理訂單的時候用處就大了，如銀行訂單，支付寶訂單，駿卡訂單等，我們都知道乙個訂單只能被處理一次，也就是說在同一時間只能有乙個執行緒處理這個訂單，等這個執行緒處理完之後，才能讓其他執行緒訪問，等這個執行緒處理完之後，其他執行緒在來訪問，就直接提示訂單的處理結果，用這個工具測試就很方便了，因為他是多個執行緒同時訪問的嗎！

開始的時候只是乙個刷部落格的工具，沒什麼用，但是最近做的乙個東西涉及到訂單處理問題，保證乙個訂單只能被處理一次，然而有的時候，乙個訂單可能同時有多個請求，當然不能乙個訂單處理多次啦，於是自己就改造了一下那個刷部落格的小工具，讓他能實現併發請求，經過這個小工具的測試，程式還ok。併發小工具截圖如下：

傳送請求

private

void action()

post(2500, txturl.text.trim());}}

//終止所有子執行緒

private

void abortthread()

threadlist.clear();

threadlist = null;}}

//啟動所有執行緒

private

void start()}//

傳送請求

private

void post(int timeout, string url)

else

--requestcount;}}

//獲取儲存指定頁面資料的流

如果位址不存在或是不能訪問，會報異常

url驗證url是否存在

private

bool checkurl(string url)

using (streamreader sr = new streamreader(mystream, encoding.default))

}return

false;

}}看雲風部落格關於解決12306併發問題的啟發：我現在做駿卡介面，可能出現併發問題，就是乙個訂單可能向我們的介面傳送多個請求，而我現在做的方法是去資料庫中對應的表驗證，看訂單是否存在，如果存在就提示一下，如果不存在按流程走，但是這個樣每來乙個訂單我都需要去資料庫查，如果我在記憶體中維護乙個訂單集合，這樣就能很快解決判斷訂單是否存在的問題，慣性思維太嚴重了，什麼都去資料庫查，這樣的效能是最差的，其實很多問題在記憶體中就可以搞定的，最近還有乙個特別感受，不要做井底之蛙，多看牛人的東西收穫真的比自己埋頭寫**進步快很多，其實很多時候我寫的程式效能差，效率低都是因為方法的原因，沒有找到好的方法，沒有靈光一閃的感覺，用了最爛的方法解決問題（這段文字是前些天寫的，跟部落格的主題關係不大）

部落格：

併發小工具

小工具 tree工具

幾個小工具

天氣小工具

併發小工具

小工具 tree工具

幾個小工具

天氣小工具

相關推薦