我有一個1生產者,M消費者線程模式。製作人從光盤讀取原始文檔並將其放置在LinkedBlockingQueue中。然後,每個消費者線程需要一個原始文件,並使用一類多線程Java正則表達式
ParsedDoc article = parseDoc(rawDocument);
的parseDoc類是一套大約20個方法有以下模式解析文檔:
public String clearContent(String document) {
Pattern regex = Pattern.compile(pattern);
Matcher matcher = regex.matcher(document);
matcher.find();
....
}
public String removeHTML(String document) {
Pattern regex = Pattern.compile(pattern);
Matcher matcher = regex.matcher(document);
matcher.replaceAll("");
....
}
我現在面臨的問題是代碼在本地(2核)機器上運行得相當快。但是當我在一臺8核心機器上運行相同的代碼時,消費者的性能會降低,幾乎停滯不前。我試圖優化jvm選項無濟於事。除去正則表達式處理步驟導致了8核心上預期的x4性能提升。所以問題是正則表達式。我意識到Pattern是線程安全的,匹配器可能需要重置()。但問題是如何重新設計正則表達式庫(在parseDoc類中),以便跨M個消費者線程安全。
任何幫助,將不勝感激
謝謝
在大多數情況下,所用的時間壓入/彈出一個任務,(即32/64位指針/參考)中,從一個隊列是多少,比處理任務&所以爭用所花費的時間要小得多不是問題。如果開發人員堅持把工作推到一個P-C隊列上,那麼只需將兩個整數加在一起,那麼當然,這不會很好地擴展。在任何合理的數據集上進行模式匹配應該適用於線程池。 – 2012-03-18 10:07:08
您是否有任何負載均衡器的例子,比普通阻塞隊列的推送/彈出消耗少得多的時間? – 2012-03-18 10:11:21
嗨阿德里安。我不確定是否正確實施了負載平衡器,但我確實遵循了您的建議。不幸的是我看不到改進。事實上,它在8核心機器上變得更糟。每個線程現在都有一個本地鏈接列表隊列,並且生產者線程讀取該線路並執行負載平衡,根據他們擁有多少負載填充每個線程的隊列。非阻塞是否爲每個消費者線程正確的數據結構? – Peyman 2012-03-19 04:23:44