迭代器和併發策略

Question

評估不同的服務器解決方案時，我需要了解Play2如何處理使用迭代器時的併發性，特別是處理Websockets請求時。

如果你看一下這個代碼顯示共享狀態的簡單的WebSocket服務器（A協作塗料應用）https://github.com/gre/playpainter/blob/master/scala/app/controllers/Application.scala

你會看到每個網頁套接字請求可以潛在地修改共享狀態，如畫家繪製或連接計數器。這段代碼是否線程安全？如果是的話（作者證實）Play2在內部處理併發性如何？在這一點上，我沒有Scala級別來不幸地完全理解play2 lib代碼。

我想知道他們如何能調解線程安全（地圖或櫃檯只能由一個線程在同一時間修改）高性能（可將多個請求「同時」處理。

唯一我可以想到的是他們將每個迭代塊的處理包裝在它自己的線程事務中;這最終嚴重限制了併發性（儘管簡化了用戶代碼）並且最終得到類似於Node.js或任何單線程服務器將提供的性能？我可以看到Iteratee編程模型在流式處理，文件處理等方面的好處，但對於每個請求觸發非平凡工作（Web服務器計算，數據庫訪問等）的websocket來說，並沒有太多好處。

Answer 1

我錯了我的應用程序的線程安全性，它有一個錯誤。

我剛剛修復它利用ConcurrentHashMap中，看到的變化https://github.com/gre/playpainter/commit/5120de5b77627836fe26602546f82c99a28cdf1b

感謝您的報告。