關於多線程鎖資源的性能與安全的新解決思路：如某個方法訪問臨界方法時，在多線程中調用該方法互不被影響的解決思路：首先：爲避免每次調用都初始化對象的耗損，用static方法，不被影響加synchronized關鍵字,但鎖資源將會成爲瓶頸 解決思路：根據threadid 個數 初始化相同個數的對象，然後各threadid調用各自持有對象的靜態方法，將不會產生。 實用範圍：該方法所在的對象不是特別大，只涉及到處理，沒有涉及到數據同步的場景之下 這樣的問題： http://manecocomph.iteye.com/blog/931545
舉例：
private static Map<Long, TxDroolsAnalyzeImpl> maps = new HashMap<Long, TxDroolsAnalyzeImpl>();
private static TxDroolsAnalyzeImpl getInstance() {
Long tId = Thread.currentThread().getId();
if (maps.containsKey(tId)) {
return maps.get(tId);
} else {
TxDroolsAnalyzeImpl txDroolsAnalyzeImpl = new TxDroolsAnalyzeImpl();
maps.put(tId, txDroolsAnalyzeImpl);
return txDroolsAnalyzeImpl;
}
}
ConcurrentLinkedQueue
一個基於鏈接節點的無界線程安全隊列。此隊列按照 FIFO（先進先出）原則對元素進行排序。隊列的頭部 是隊列中時間最長的元素。隊列的尾部 是隊列中時間最短的元素。新的元素插入到隊列的尾部，隊列獲取操作從隊列頭部獲得元素。當多個線程共享訪問一個公共 collection 時，ConcurrentLinkedQueue 是一個恰當的選擇。此隊列不允許使用 null 元素。
需要小心的是，與大多數 collection 不同，size 方法不是 一個固定時間操作。由於這些隊列的異步特性，確定當前元素的數量需要遍歷這些元素。
此類及其迭代器實現了 Collection 和 Iterator 接口的所有可選 方法。
內存一致性效果：當存在其他併發 collection 時，將對象放入 ConcurrentLinkedQueue 之前的線程中的操作 happen-before 隨後通過另一線程從 ConcurrentLinkedQueue 訪問或移除該元素的操作。
LinkedBlockingQueue
一個基於已鏈接節點的、範圍任意的 blocking queue。此隊列按 FIFO（先進先出）排序元素。隊列的頭部 是在隊列中時間最長的元素。隊列的尾部 是在隊列中時間最短的元素。新元素插入到隊列的尾部，並且隊列獲取操作會獲得位於隊列頭部的元素。鏈接隊列的吞吐量通常要高於基於數組的隊列，但是在大多數併發應用程序中，其可預知的性能要低。
可選的容量範圍構造方法參數作爲防止隊列過度擴展的一種方法。如果未指定容量，則它等於 Integer.MAX_VALUE。除非插入節點會使隊列超出容量，否則每次插入後會動態地創建鏈接節點。