我在我的CF應用程序中使用了雙重檢查鎖定的版本（在我知道什麼是雙重檢查鎖定之前）。ColdFusion中「雙重鎖定鎖定」是否工作？
本質上，我檢查一個對象的存在。如果它不存在，我會鎖定（通常使用一個命名鎖），然後再嘗試創建該對象，然後再次檢查是否存在。我認爲這是一個很好的方法來停止創建多個對象並停止系統中的過度鎖定。
這似乎工作，因爲沒有過多的鎖定和對象重複不會被創建。不過，我最近了解到，Double Checked Locking dosn't work in Java，我不知道的是，如果這在CF中成立，看到CF線程和鎖與本地Java線程和鎖並不完全相同。
Java是線程安全的，所以它不是那麼多，你的鎖不會工作，因爲它們不是必需的。基本上，在CF 6+中，需要使用鎖來防止競爭條件或創建/刪除Java控制之外存在的對象（例如文件）。
爲了增加Ben Doom所說的關於Java的內容，這在ColdFusion中是相當標準的做法，特別是在設置應用程序變量的應用程序初始化例程中。
如果沒有至少一個鎖，那麼您讓初始匹配到您的Web應用程序都會同時初始化應用程序變量。這假設您的應用程序足夠忙，以保證這一點。如果您的應用程序在您的應用程序首次啓動時處於繁忙狀態，則危險僅限於此。
第一個鎖確保一次只有一個請求初始化您的變量。
嵌入在第一個鎖中的第二個鎖將檢查以確保存在初始化代碼末尾定義的變量，例如application.started。如果存在，用戶將被踢出。
雙鎖定模式已將我的皮膚保存在繁忙的站點上，但是，對於非常繁忙的站點，應用程序初始命中完成請求的隊列可能會過快，過快，並導致服務器崩潰。這個想法是，這些請求正在等待第一個命中，這是緩慢的，然後第二個中斷到第一個cflock，並很快被拒絕。隨着隊列中的數百或數千個請求，每毫秒都在增長，它們都彙集到第一個cflock塊。解決方案是在第一個cflock上設置一個非常低的超時時間，而不是拋出（或捕捉並且鴨子）鎖超時錯誤。
最後，我描述的這種行爲已經被Application.cfc的ColdFusion 7的onApplicationStart（）方法所棄用。如果你正在使用onApplicationStart（），那麼你不應該爲你的應用程序init例程鎖定。 Application.cfc已被鎖定。
總而言之，是的，雙重檢查鎖定在ColdFusion中起作用。這在某些情況下很有幫助，但是要正確。我不知道爲什麼它的工作原理與Java的線程模型不同，可能是在ColdFusion服務器的後臺手動檢查某種查找表。
我明白這個機制，但很驚訝地發現，由於java的優化器無法工作（請參閱鏈接），我不知道它在java中的工作原因是否也適用於ColdFusion。 – 2009-02-17 09:33:10
要打開蠕蟲的一個整體的其他罐頭...
你爲什麼不使用依賴注入庫，如ColdSpring，跟蹤你的對象，防止循環依賴。
事實上，我認爲他們是必要的，以防止內森描述的競爭條件。 – 2009-02-18 16:58:18
@丹·羅伯茨：這就是我所說的。 – 2009-02-20 16:46:11