并行程序中同步瓶頸的檢測和優化方法*

張 楊，李柳旭

(河北科技大學 信息科學與工程學院, 河北 石家莊 050018)

鎖是并行程序中比較通用的同步控制方式之一，主要用于在并發程序中確保數據訪問和程序狀態的正確性。然而在多核時代鎖的使用容易導致鎖競爭問題，該問題是由多個線程同時競爭臨界區資源引起的，如果一個線程獲得了鎖，那么其他想獲取該鎖的線程都將被阻塞，直到持有該鎖的線程釋放鎖。由于鎖競爭會使多核處理器中只有一個處理核處于運行狀態，其他處理核只能等待，嚴重降低并行程序性能。目前關于鎖競爭的研究有很多，例如，Sch?rgenhumer等[1]通過JVMTI和字節碼檢測工具來收集有關Java應用程序中鎖競爭的詳細信息；Patros等[2]通過修改Java虛擬機記錄線程駐留時鎖競爭的數據信息；Zheng等[3]通過記錄程序執行并且跟蹤分析來識別不必要的鎖競爭；Feng等[4]在程序運行時動態檢測操作系統在Java應用程序上引起的鎖競爭。

不恰當的同步控制會進一步加劇鎖競爭，導致程序性能下降。為此，Rinard等[5]介紹了自適應復制技術，自動消除在對象上執行原子操作的多線程程序中的同步瓶頸。目前還有一些研究通過性能指標來識別性能瓶頸[6-7]。Free Lunch[8]工具通過計算線程在某個時間間隔內獲取鎖花費的時間百分比檢測由鎖導致的性能瓶頸。

很多學者對并行程序性能分析進行了研究。Trahay[9]在運行應用程序時收集數據，設計方法來檢測OpenMP應用程序中的可伸縮性問題。Selakovic等[10]通過靜態模式匹配性能問題。Kroening等[11]提出了針對C/Pthread的靜態死鎖分析，識別與死鎖分析有關的語句，但靜態分析有時存在誤報率較高的缺陷。Zhang等開發的框架VarCatcher[12]使用并行特征向量來分析結果，通過查看不同的執行模式，在多個運行中查找多個程序執行之間會出現性能差異的地方。QURO[13]是一個查詢感知的編譯器，它可以基于鎖競爭自動在事務代碼內對查詢進行重新排序，同時保留程序語義以提高性能。Cicirelli[14]用Max-Plus函數證明了在局部同步情況下效率存在一個非零下限，相對于全局同步具有一定優勢。有一些研究[15-16]利用分散的鎖管理器來實現高性能，NetLock[17]是新的集中式鎖管理器，在不犧牲策略支持靈活性的情況下實現高性能。WAIT[18]工具為了測量鎖的使用情況，對獲取鎖時被阻塞的線程數進行統計。GAPP[19]工具無須通過檢查源碼就可識別并行程序中的一系列瓶頸。Tallent等[7]提出并評估了3種鎖競爭問題，分析了鎖競爭導致的性能損失。然而，目前研究在檢測性能瓶頸的同時未進一步提出優化建議。

關于針對并發程序的優化，Diniz等[20]對同一鎖上過于頻繁的同步進行粗化，以減少鎖開銷。Zhang等[21]將內置監視器轉換為StampedLock，通過細化鎖的方式減輕鎖競爭的影響。Curtsinger等[22]使用因果分析方法來識別具有優化機會的代碼。Yu等[23]提出了基于跟蹤的動態方法來識別一般性能問題，并拆分鎖來提升性能。Arbel等[24]提出了一個用于并發數據結構的代碼轉換方法，它在不犧牲正確性的情況下提高程序的可伸縮性。

從目前的研究現狀來看，鎖導致的性能瓶頸檢測研究仍存在以下問題：①已有方法采用單一靜態分析或動態分析，然而靜態分析導致誤報率較高，動態分析雖然可以增加準確性，但會導致檢測時間顯著增加，目前還沒有采用動靜結合的方法來檢測同步瓶頸；②對于鎖導致的性能瓶頸認識不清，對于如何檢測鎖導致的性能缺陷還需要進一步研究；③已有的方法雖然檢測了性能瓶頸，但需要對這些性能瓶頸提出進一步優化建議。

針對目前研究存在的問題，本文提出了同步瓶頸檢測和優化方法，該方法針對并行程序中鎖相關代碼，采用動靜結合分析技術分析同步依賴關系，構建同步依賴圖。通過增加程序工作負載，監測同步依賴圖中所有臨界區的變化來檢測同步瓶頸。

1 研究動機

在并行程序中，只有一個線程處于運行狀態，其他線程處于空閑狀態。若臨界區中存在耗時且不必要的同步操作，增加程序工作負載后，臨界區執行時間增加，加劇鎖競爭。這里以Apache的Xalan[25]工具中的releaseXMLReader()方法為例說明鎖導致的性能瓶頸問題。該方法首先判斷閱讀管理器是否為空，若不為空則調用XMLReaderManager類中的releaseXMLReader()方法釋放閱讀器。該方法的執行情況如圖1所示，圖1(a)表示該方法增加工作負載之前的執行情況，可以看出線程1首先獲得鎖L1進入臨界區CS1，當線程1釋放該鎖后線程2、線程3、線程4和線程5依次獲取鎖L1進入臨界區CS1，虛線表示等待時間。圖1(b)為增加程序工作負載后該方法的執行情況，可以看出在增加程序工作負載后，在每次臨界區執行完之后會有1 ms的空閑，這可能是由于該方法中判斷閱讀管理器是否為空是讀操作，使用同步鎖導致程序的等待，加劇了其他4個線程競爭臨界區CS1資源的情況。

(a) 增加負載前(a) Before increasing the load

2 檢測和優化框架

本節首先給出了方法的整體框架，然后對框架中的每個部分進行詳細介紹。

2.1 方法框架

檢測和優化并發程序中同步瓶頸的方法IdeSync。該方法首先進行靜態同步依賴分析，使用控制流分析生成源程序對應的控制流圖，再通過訪問者模式分析遍歷控制流圖，檢測源程序中的同步代碼塊和同步方法?？紤]到同一個鎖對象可能存在別名現象，使用別名分析找到存在別名的鎖對象，增加靜態同步依賴關系的準確性。在靜態同步依賴關系的基礎上結合程序執行路徑進行動態同步依賴分析。通過增加程序的工作負載，在程序執行過程中監測同步依賴圖中所有臨界區的變化，檢測同步瓶頸。最后針對發現的同步瓶頸提出優化建議，并通過重構程序進行優化，方法框架如圖2所示。

圖2 IdeSync方法框架Fig.2 Framework of IdeSync

2.2 動靜結合同步依賴關系分析

本節采用動靜結合分析技術分析同步依賴關系，構建同步依賴圖，采用動靜結合分析技術增加了靜態分析同步依賴關系的準確性，同時也降低了動態分析同步依賴關系的分析時間。

2.2.1 靜態同步依賴關系分析

在源碼的基礎上使用控制流分析、訪問者模式分析和別名分析靜態分析方法。通過控制流分析生成有向控制流圖，控制流圖上包含程序執行的節點，其中包含監視器的進入和退出指令，同步代碼塊的開始是監視器的入口指令MonitorEnter，同步代碼塊的結束是監視器的出口指令MonitorExit。然后，使用訪問者模式遍歷源碼，檢測被synchronized修飾的同步方法，如果該方法是靜態同步方法，則監視器對象是當前類的對象，如果該方法是同步方法，則監視器對象是當前類的實例對象。主要分析了以下4種同步依賴關系：同步方法之間存在調用關系；同步方法中存在同步塊；同步塊之間存在嵌套關系；同步塊中調用同步方法。

同步依賴圖T=(P，S)，P為結點，S為邊。P={P1，P2，…，Pn}，Pi表示源程序中的同步方法或同步塊，其中1≤i≤n。S={Pi→Pj}，表示Pi為Pj的父結點，Pj依賴于Pi。構建靜態同步依賴圖的算法如算法1所示。首先生成臨界區對應的中間表示IR，然后通過IR生成對應的指令集Ins，對每一條指令i進行遍歷，調用buildGraph()方法構建同步依賴圖(行1～4)。如果指令i為方法調用指令，則對該臨界區指令集Ins1中的指令i1進行遍歷；若指令i1為MonitorEnter指令，說明同步方法中存在同步塊，則添加結點PM1、PB1和邊S={PM1→PB1}(行9～10)；若指令i1為方法調用指令，說明同步方法中調用了同步方法，則添加結點PM2、PM3和邊S={PM2→PM3}(行11～12)；若指令i為MonitorEnter指令，則對該臨界區指令集Ins2中的指令i2進行遍歷；若指令i2為方法調用指令，說明同步塊中存在同步方法，則添加結點PB4、PM4和邊S={PB4→PM4}(行18～19)；若指令i2為MonitorEnter指令，說明同步塊中存在同步塊，則添加結點PB5、PB6和邊S={PB5→PB6}(行20～21)。被關鍵字synchronized修飾的同步方法和同步塊都持有相應的鎖對象，可能存在鎖對象不同但指向同一內存地址，因此需要進行別名分析，增加同步依賴分析的準確性。

算法1 構建靜態同步依賴圖

以SPECjbb2005中primeWithDummyData()方法為例，部分靜態同步依賴情況如圖3所示，圖中每個結點與該結點的子結點存在同步依賴關系，序號1～19代表圖中的19個結點。從圖3中可以看出，多個節點之間存在相關的依賴關系，而且節點2對節點7和8都存在依賴關系。

圖3 靜態同步依賴圖Fig.3 Static synchronization dependency graph

2.2.2 動態同步依賴關系分析

對于給定的一個測試用例，使用動態分析獲取程序的執行路徑，使用JProfiler提供的API生成可記錄的信息進行分析。首先為執行路徑中出現的臨界區創建節點，對存在等待關系的臨界區添加邊，用虛線表示；然后結合靜態同步依賴圖，判斷執行路徑中的臨界區之間是否存在靜態依賴關系，若有則添加邊，用實線表示；最后刪除執行路徑中不存在等待關系和靜態依賴關系的節點。

圖4為SPECjbb2005的部分同步依賴圖，圖中的CS2對應圖3中的primeWithDummyData()方法，CS3對應圖3中loadInitialOrders()方法，由于CS2和CS3存在靜態依賴關系，因此添加實線邊，線程1中的CS1和線程2中的CS1之間的虛線表示存在等待關系。

圖4 部分同步依賴圖Fig.4 Partial synchronization dependency graph

2.3 監測臨界區

在依賴圖的基礎上，對臨界區的執行進行監控。首先，給定一個測試用例以及測試用例的一組工作負載W={W1，W2，…，Wn}，以不同的工作負載執行程序監測臨界區在不同工作負載下執行時間、臨界區等待時間和CPU使用率的變化。需要監測同步依賴圖中出現的臨界區，并考慮同步依賴圖中臨界區之間的同步依賴關系來確定同步瓶頸。靜態分析可以盡可能發現全部臨界區，動態分析需要根據特定的執行路徑，會暴露某些執行路徑上的執行情況。

判斷增加工作負載后程序中的臨界區是否滿足以下3個條件，判定該臨界區是否為同步瓶頸。①臨界區執行時間明顯增加；②臨界區的CPU使用率穩定；③臨界區增加額外等待時間。

隨著工作負載的增加，臨界區執行時間通常也會增加。當增加工作負載后，如果臨界區執行時間明顯增加但CPU使用率穩定，則該臨界區可能存在性能問題。然后，判斷該臨界區是否增加額外等待時間。將增加額外等待時間定義為：工作負載分別為W1和W2時，因競爭臨界區資源增加的等待時間。結合同步等待關系發現同步瓶頸，此外需要根據同步依賴圖中臨界區之間的靜態同步依賴關系進一步確定判定為同步瓶頸。例如，增加工作負載后，若圖4中在CS2與CS3處增加的額外等待時間相同，則認為CS2增加的額外等待時間是由與其存在靜態依賴關系的CS3導致的，因此，判定CS2不是同步瓶頸，CS3是同步瓶頸。

2.4 優化

以實現程序最大并行度為原則，對同步瓶頸進行優化。同步鎖為互斥鎖，讀寫鎖可以提供比互斥鎖更好的并行性。首先考慮對不必要的同步進行鎖消除來緩解開銷，然后對無法進行鎖消除的同步瓶頸采用粗粒度的讀寫鎖，即讀鎖、寫鎖和鎖分解，替換同步鎖增加程序的并行度，并在必要時添加細粒度的讀寫鎖來緩解同步瓶頸，即鎖降級。因此，使用5種同步瓶頸優化模式：鎖消除、讀鎖、寫鎖、鎖分解和鎖降級。

1)鎖消除：同步依賴圖中一條邊連接的兩個臨界區內均只存在讀操作。

2)讀鎖：臨界區內只包含讀操作。

3)寫鎖：臨界區內只包含寫操作。

4)鎖分解：臨界區內不存在if判斷語句，但同時存在讀操作和寫操作。

5)鎖降級：臨界區內只存在一個if語句且if語句最后有寫操作和至少一個讀操作。

負面效應分析用于分析臨界區并生成讀寫字符序列，R代表讀操作，W代表寫操作，如果操作、方法或表達式修改了其本地環境之外的狀態，會產生負面效應。遍歷指令集中的每條指令，判斷臨界區內是否有寫指令，若有則返回W，否則返回R，輸出臨界區的讀寫字符序列。根據讀寫字符序列確定同步瓶頸優化模式并進行重構，具體實現算法如算法2所示。首先輸入同步依賴圖中一條邊連接的兩個臨界區：如果兩個臨界區為兩個不同的臨界區，則判斷兩個臨界區內是否只存在讀操作，若是，則消除后者的同步鎖(行1～4)；如果兩個臨界區表示同一個臨界區，則調用refactor()方法分析兩個臨界區的讀寫字符序列(行5～7)，若輸入為圖4線程1中的CS1和線程2中的CS1，則只需分析一次CS1的讀寫字符序列即可。獲取臨界區內if條件判斷語句的數量(行9～15)，如果臨界區內不存在if語句，當臨界區的讀寫字符序列為RW或WR時，將同步鎖分解為讀鎖和寫鎖(行17～18)，當臨界區的讀寫字符序列為R時，將同步鎖替換為讀鎖(行19～20)，當臨界區的讀寫字符序列為W時，將同步鎖替換為寫鎖(行21～22)。如果臨界區內存在一個if條件判斷語句且if語句最后有寫操作和至少一個讀操作時，將進行鎖降級(行24～25)。如果臨界區不滿足上述所有條件，則使用寫鎖(行26)。

算法2 重構算法

3 實驗評估

本節對提出的檢測方法IdeSync進行評估，首先對實驗環境配置和選取的應用程序進行介紹，然后給出實驗結果，并對結果進行分析。

3.1 環境配置

所有實驗都在配有2.30 GHz英特爾酷睿i5 CPU和4 GB RAM的筆記本電腦上進行，操作系統使用64位Windows10系統，安裝了JDK 1.8.0_271、Eclipse 4.13.0、WALA 1.5.3[26]和JProfiler 11.1.4[27]。

3.2 研究問題

RQ1：使用IdeSync方法，是否可以有效發現每個應用程序中的同步瓶頸？

RQ2：檢測到的同步瓶頸在5個優化模式中的分布情況如何？

RQ3：同步瓶頸優化后的程序性能是否有所提升？

3.3 應用程序

選取的應用程序包括HSQLDB[28]、Jenkins[29]、JGroups[30]、SPECjbb2005[31]、Xalan[25]、RxJava[32]、Antlr[33]、Fop[34]、Kafka[35]、MINA[36]、Cassandra[37]和Jmeter-plugins[38]。HSQLDB是開源的Java數據庫，Jenkins是一個開源的自動化服務器，SPECjbb2005是Java應用服務器測試程序，JGroups是群組通信工具，Xalan和Fop分別是Apache公司的XSLT轉換處理器和格式化對象處理器，RxJava是Netflix公司的在Java VM上使用可觀測的序列來組成異步的、基于事件的程序的庫，Antlr是一個解析器生成器，Kafka是由Apache軟件基金會開發的開源流處理平臺，MINA是Apache公司的網絡應用框架，Cassandra是Apache公司的開源分布式NoSQL數據庫系統，Jmeter-plugins是Apache JMeter工具的一組獨立插件。這些應用程序的版本號信息、源代碼行數、同步方法和同步塊數量見表1。

表1 應用程序及其配置

為了暴露同步瓶頸，針對不同應用程序選擇了不同的工作負載。對于HSQLDB應用程序，通過增加客戶數增加工作負載，分別為10、20、30、40；對于Jenkins應用程序，通過增加轉移作業的數量增加工作負載，分別為50、100和150；對于SPECjbb2005應用程序，通過增加線程數增加工作負載，分別為1、2、3、4、5、6、7、8；對于JGroups應用程序，通過增加郵件數量增加工作負載，分別為1×106、2×106、3×106；對于Xalan應用程序，通過增加XML文檔的數量增加工作負載，分別為1 000、1 500、2 000；對于RxJava應用程序，通過增加測試基準測試的數量增加工作負載，分別為12、24、36、47；對于Antlr應用程序，通過增加測試使用舊的和新的unicode流機制對某些unicode字形進行lex的速度的數量增加工作負載，分別為400、600、800；對于Fop應用程序，通過增加復制測試文件的數量增加工作負載，分別為100、200、300；對于Kafka應用程序，通過增加打印轉換文檔的數量增加工作負載，分別為20、40、60；對于MINA應用程序，通過向服務器發送消息的數量增加程序的工作負載，分別為1 000、2 000、4 000；對于Cassandra應用程序，通過增加忙碌的工作線程數量增加程序的工作負載，分別為1、2、3、4、5、6、7、8；對于Jmeter-plugins應用程序，通過增加循環的次數增加程序的工作負載，分別為20、40、60。

3.4 實驗結果及分析

3.4.1 RQ1的評估

為了回答RQ1，對選取的12個應用程序中同步鎖數量、同步瓶頸數量以及同步瓶頸所占同步鎖的百分比進行了統計，如表2所示。從實驗數據中可以看出，在12個應用程序中共檢測到了72個同步瓶頸，有50個同步瓶頸主要分布在HSQLDB、SPECjbb2005和JGroups中，SPECjbb2005中存在的同步瓶頸數量最多，同步瓶頸百分比為13.2%；在MINA中只發現了1個同步瓶頸，但由于該程序中的同步鎖數量較少，同步瓶頸所占的百分比高達8.3%，其次是在SPECjbb2005和Antlr中；在RxJava和Fop中同步鎖數量比較少，因此共發現了3個同步瓶頸；雖然Kafka、Jenkins和Cassandra中的同步鎖數量較多，但是在Kafka中只存在6個同步瓶頸，Cassandra中只存在2個同步瓶頸，Jenkins中未發現同步瓶頸。

表2 同步瓶頸情況

3.4.2 RQ2的評估

為了回答RQ2，對滿足5個優化模式的同步瓶頸進行了統計，如表3所示。第3～7列分別為5種優化模式對應的同步瓶頸數量。從應用程序角度可以看出，只有HSQLDB、SPECjbb2005和Xalan中存在鎖消除的情況；HSQLDB和SPECjbb2005中同步瓶頸數量較多，這兩個應用程序中的同步瓶頸涵蓋了5種優化模式；JGroups中同步瓶頸數量相對較多，但沒有建議進行鎖消除和鎖分解的同步瓶頸；在Xalan和Kafka中均包含6個同步瓶頸，Xalan中沒有建議進行鎖分解的同步瓶頸，Kafka中沒有建議進行鎖消除的同步瓶頸；Fop和MINA中都只有1個同步瓶頸且均建議使用讀鎖；Antlr中的兩個同步瓶頸均建議進行鎖降級。從優化模式角度可以看出，檢測到的72個同步瓶頸中建議進行鎖消除的只有5個；有24個建議使用讀鎖，有4個建議進行鎖分解，有11個建議進行鎖降級，這3種優化在一定程度上都可以增加程序的并行度；建議使用寫鎖的有28個，其中來源于SPECjbb2005的有15個，在其他程序中建議使用寫鎖的情況較少。

表3 同步瓶頸在優化模式中的分布情況

將IdeSync和目前已有的重構工具ReLocker[39]進行了對比。ReLocker是一個可以在不同鎖機制之間進行轉換的自動重構工具， ReLocker工具在2010年被提出，只支持JDK1.6版本。計劃將表1中所有程序進行兩個工具對比，然而由于ReLocker版本問題，只找到了HSQLDB和Cassandra兩個程序的適用版本，分別為1.8.0.10和0.4.0，由于版本差異，這兩個程序中鎖的數量跟表1中程序版本的數量略有不同，HSQLDB和Cassandra分別含有266個和57個同步鎖。

表4給出了ReLocker和IdeSync重構結果的對比。在ReLocker中，對HSQLDB測試程序分別推薦了31個讀鎖和212個寫鎖，然而存在23個不能重構的問題；這種不能重構的問題在Cassandra中仍然存在，但數量僅有3個。相比之下，IdeSync不僅可以推斷讀鎖和寫鎖，而且不存在不能重構的問題，它可以實現更為細粒度的鎖重構，不僅推薦了一定數量的鎖分解和鎖降級，而且還推斷鎖消除的情況，這表明IdeSync可以更好地對鎖的使用進行優化。從總體來看，IdeSync性能要優于ReLocker。

表4 ReLocker和IdeSync對比

3.4.3 RQ3的評估

為了回答RQ3，對不恰當地使用同步鎖而限制了程序并行執行的同步瓶頸進行優化，并選取了HSQLDB、JGroups、SPECjbb2005和Antlr應用程序，對同步瓶頸優化前后的程序性能進行對比。

在HSQLDB程序中，同步瓶頸所在的方法分別為writeCommitStatement()、initPool()、getStore()、prepareStatement()、connect()、executeQuery()、setInt()、createStatement()、forceSync()、writeDeleteStatement()、writeRowOutToFile()、newSession()、getBundleHandle()和nextTask()。選取測試程序JDBCBench，測試優化前后事務數分別為1×105、2×105、3×105、4×105時，程序每秒處理事務的情況，結果如圖5所示。從結果可以看出，隨著處理事務數的增加，程序并行執行效果越明顯，事務率均有不同程度的提高，分別提高了1.8%、4.8%、6.2%和8.4%。

圖5 HSQLDB的性能對比Fig.5 Performance comparison in HSQLDB project

在JGroups程序中，同步瓶頸所在的方法分別為convertViews()、getThreadName()、startInfoSender()、startViewConsistencyChecker()、start()、clearViews()、addInfo()、installView()、adjustSuspectedMembers()、getNewThreadName()和addChannelListener()。選取測試程序RoundTripRpc和UnicastTestRpc，測試優化前后兩個群組間消息的發送與接收能力，結果如圖6所示。從結果中可以看出，優化后兩個程序的請求處理率分別提高了4.8%和4.5%。

圖6 JGroups的性能對比Fig.6 Performance comparison in JGroups project

在SPECjbb2005中，同步瓶頸所在的方法分別為newOrderIter()、getOrderPtr()、removeNewOrder()、addOrder()和process()等。程序優化前后的運行結果如圖7所示。從結果中可以看出，在線程數為1、2和3時，優化前的堆內存使用比低于優化后的堆內存使用比，隨著線程數的增加，當線程數為4、5、6、7和8時，優化后的堆內存使用比均低于優化前的堆內存使用比，分別減少了12.7%、36.9%、23.5%、1.1%和6.8%。

圖7 SPECjbb2005的性能對比Fig.7 Performance comparison in SPECjbb2005 project

在Antlr中，同步瓶頸所在的方法分別為addDFAState()和addDFAEdge()。選取了測試程序TimeLexerSpeed，測試了優化前后使用舊的unicode機制對元素進行測試，結果如圖8所示。從結果中可以看出，元素數為400時優化后花費的時間高于優化前花費的時間，但隨著元素數量的增加，當元素數為600和800時，優化后花費的時間比優化前花費的時間均有所下降，分別縮短了2.1%和2.8%。

圖8 Antlr的性能對比Fig.8 Performance comparison in Antlr project

通過對RQ3的評估，發現在SPECjbb2005程序中線程數為1、2和3時，以及在Antlr程序中元素數為400時，優化后程序性能未得到提升，這可能是由于優化后讀寫鎖的獲取和釋放操作帶來的開銷所導致的，當程序線程任務或負載較小時，優化操作所需的開銷高于優化效果。

3.5 有效性威脅

本節對實驗過程中威脅有效性的幾個因素進行了討論：

1)由于并發程序執行的不確定性，性能測試的實驗數據可能在一定范圍內上下浮動。為了確保實驗數據的有效性，所有實驗結果都是在10次運行的基礎上取平均值得到的。

2)本實驗只選取了12個應用程序進行了評估，它們并不能代表所有程序。為了緩解這個有效性威脅，盡量選用涉及數據庫、服務器等多個領域的程序。

4 結論

本文提出了檢測和優化同步瓶頸的方法IdeSync。該方法首先使用靜態分析方法檢測程序源碼中的同步方法和同步塊，采用動靜結合分析技術分析同步依賴關系，構建同步依賴圖，增加了靜態分析同步依賴關系的準確性，降低了動態分析同步依賴關系的難度。然后增加程序工作負載，監測臨界區的變化檢測同步瓶頸，最后針對檢測到的同步瓶頸，給出優化建議，并在Eclipse JDT框架下以插件的形式實現自動優化重構工具。在實驗中選取HSQLDB、SPECjbb2005和RxJava等12個大型實際應用程序驗證了該方法的有效性。在接下來工作中，將使用更多的應用程序和更大規模的測試集對IdeSync方法進行驗證。