我提出這些問題，因爲我在一個多線程的代碼異步請求使用的CookieContainer。我不能把一個異步的請求放在一個鎖中。也許我必須使用只讀的「變量」（或不可變的類型），如在F＃中，對吧？.NET System.Net.CookieContainer線程安全嗎？
不，不是所有的.NET類都是線程安全的。事實上，很少有需要。一般來說，靜態成員應該是線程安全的，但這是關於它的。
不可變/半不可變對象自動線程安全（這包括像XslTransform等） - 並且有一些可變的少數情況（例如線程容器），您可以期望事情是線程安全的。 MSDN爲每個類聲明線程安全。
我不會期望cookie容器是線程安全的，所以你可能必須自己同步它。
（更新）
重新提出你的第二點;你正在考慮哪些變量？在異步請求期間，您自己的本地狀態變量將不會直接更新，因此在準備請求時處理響應時，簡單地由您來同步訪問。最常見的是，通過Monitor - 即
lock(syncLock) {
// prepare request from (synchronized) state
req.Begin{...}
}
，然後在回調
lock(syncLock) {
// ...read values from request...
// ...update local state...
}
哪裏syncLock只是一個鎖定對象（或許舉行鍼對一個實例）：
private readonly object syncLock = new object();
我不知道HttpWebRequest.CookieContainer更新哪一點，但我想它是在異步請求期間。 – 2008-12-28 18:39:36
那麼，你需要從同一個對象發出併發請求嗎？你不能有多個HttpWebRequest對象與單獨的Cookie容器？那麼就沒有衝突。 – 2008-12-28 20:56:47
所有.NET框架中的靜態類由Microsoft保證是線程安全的。
您可以使用Reflector進行驗證。
只是一個說明，網頁發送一個修改後的cookie列表作爲其HTTP答覆的一部分。在發送回覆之後修改CookieContainer將無法完成任何事情 - 您只需修改不再存在的頁面請求的Cookie集合即可。
正如我所看到的（在Reflector的幫助下），CookieContainer在內部使用鎖來訪問其成員，所以它應該是線程安全的，儘管有文檔。
順便說一下，它根本沒有公共靜態成員。所以在我看來，文檔只提供了一個標準的通知。
我會更新重新第二，只是爲了勾選一切... – 2008-12-28 18:20:36