說明，翻譯文章為A Systematic Review and an Evaluation of Static Analysis Tools中的Chapter 3 – An Evaluation of Static Analysis Tools for Java Multithreaded Bugs。
正文：
Java多線程錯誤的靜態(tài)分析工具的評估
摘要：
靜態(tài)分析（SA）工具正用于早期檢測軟件缺陷。隨著多核處理器的發(fā)展，已經(jīng)使得從服務(wù)器到個人計算機的軟件并發(fā)成為可能。從本質(zhì)上講，并發(fā)性錯誤與順序程序中的錯誤不同，它們很難被檢測到?？捎玫腟A工具提供對檢測并發(fā)錯誤的支持。然而關(guān)于SA工具檢測Java多線程錯誤的有效性的實證證據(jù)不是那么強。本文介紹了評估四個靜態(tài)分析工具檢測Java并發(fā)性錯誤和錯誤模式的結(jié)果。使用并發(fā)基準測試程序和多線程錯誤模式的集合來評估這些工具。除了工具的評估，我們已經(jīng)從工具的檢測器和文獻中識別了87個獨特的錯誤模式。最后，我們對工具的錯誤模式檢測器進行了分類，這將有助于用戶更容易地理解和使用它們。
1介紹
寫并發(fā)軟件很困難，然而，檢測并發(fā)缺陷甚至更困難。在過去幾十年中，開發(fā)合適的技術(shù)和工具來檢測并發(fā)軟件缺陷，已經(jīng)花費了大量的工作。因此，我們有各種類型的工具，如靜態(tài)分析器，模型檢查器和動態(tài)分析器[6,18]。 靜態(tài)分析（又名自動靜態(tài)分析）工具能夠檢測源代碼中的缺陷，而不執(zhí)行它。模型檢查器使用調(diào)用圖，有限狀態(tài)機等以良好定義的數(shù)學(xué)公式對源代碼進行形式驗證[18]。 動態(tài)分析器需要執(zhí)行檢測缺陷的代碼。
通常，靜態(tài)分析（SA）工具在檢測錯誤方面比動態(tài)工具更抽象。SA工具是可擴展的，其中模型檢查工具遭受狀態(tài)爆炸問題。動態(tài)工具不像SA工具那么容易使用; 因為使用動態(tài)工具檢測錯誤需要儀器源代碼或目標代碼[6]。
在軟件開發(fā)中，早期漏洞檢測的重要性是一個公認的事實。靜態(tài)分析工具有缺陷[ 17,19 ]早期檢測和降低軟件開發(fā)的成本[ 3 ]。實證研究表明，使用SA工具與代碼檢查并發(fā)軟件是成本效益的[ 28 ]。通常，SA工具部署在開發(fā)人員的工作站上，并與編碼一起使用足夠快。它也可以用來作為一個批處理器，用于測試大量的代碼。然而，重要的是，在任何其他測試工具或技術(shù)使用之前，SA工具通?？梢杂脕頇z查代碼。
一些研究評估了在不同的靜態(tài)分析工具下的java程序[ 2,5,20,21,23-26 ]。然而，很少有研究關(guān)注java多線程的缺陷[ 1的靜態(tài)分析工具的評價，25 ]。大多數(shù)這些嘗試是局部的多線程的缺陷，因為它們沒有涵蓋廣泛的并發(fā)缺陷類型。更多的經(jīng)驗證明，評估不同的缺陷檢測工具，專門專注于不同類型的錯誤和錯誤模式是必要的。
本研究測評了兩種商業(yè)版和兩種開放源代碼版的靜態(tài)分析工具，主要測試他們java多線程的錯誤和缺陷模式檢測能力。為了評價靜態(tài)分析工具，我們使用了java程序的基準測試套件，套件包含并發(fā)錯誤[ 7 ]和從一個反模式[ 12 收集的錯誤模式]和選定的工具庫。本研究解決以下研究問題：
問題一：在java多線程的錯誤檢測和錯誤模式的靜態(tài)分析工具的有效性如何？
問題二：:商業(yè)SA工具和開源SA工具在檢測java多線程的缺陷時哪一個更好？
我們進行了一個實驗來回答這些問題，其中SA工具作為主題，基準套件和錯誤模式作為對象。除了評估工具之外，我們還對工具使用的規(guī)則/檢查/錯誤模式進行了分類，以檢測缺陷。這種分類可以幫助用戶理解和根據(jù)自己的需要選擇一套合適的跳棋/錯誤模式。我們還利用工具研究了bug模式檢測器，然后統(tǒng)一了87個獨特的java多線程的錯誤模式。
研究結(jié)果表明，商業(yè)工具Jtest在檢測Java多線程錯誤方面比其他工具更好，缺點是該工具報告的假陽性率很高。然而，不可能在商業(yè)和免費開源工具之間做出明確區(qū)分，因為其他商業(yè)工具Coverity Prevent檢測到工具中缺陷的數(shù)量最少。 FindBugs和Coverity Prevent都報告了少量的假陽性警告。
第2節(jié)討論了并發(fā)性錯誤和錯誤模式。 第3節(jié)介紹用于測試工具的選定工具和一組程序。 第4節(jié)解釋了唯一的bug模式及其分類的識別。 實驗詳見第5節(jié)。第6節(jié)討論分析和結(jié)果。 討論和相關(guān)工作分別在第7節(jié)和第8節(jié)討論，在第9節(jié)結(jié)束。
2并發(fā)錯誤以及錯誤模式
并發(fā)軟件的最常見的特性是非確定性。 并發(fā)程序的非確定性執(zhí)行使其與順序程序不同。 因為線程的交織執(zhí)行，并發(fā)程序保持非確定性特性，出現(xiàn)了許多問題，如數(shù)據(jù)競爭，原子性違反，同步缺陷，死鎖，活鎖等。
并發(fā)問題可以分為兩種類型的基本屬性，安全性和活性[18]。 安全屬性確保在程序執(zhí)行期間不會發(fā)生任何不良。另一方面，活力屬性表示好東西最終會發(fā)生。這些屬性下的最著名的問題是競爭條件（也稱為數(shù)據(jù)競爭，交織問題），死鎖，活鎖和饑餓[18]。 這些問題必須在程序中不存在，以滿足安全性和活性。并發(fā)軟件的這兩個基本屬性是抽象的，一些并發(fā)問題在它們之間重疊。出于這個原因，基于基本屬性對并發(fā)性問題進行分類并沒有成果。
在軟件工程中，模式意味著，一些常見的技術(shù)來記錄和重用特定的和重要的例子。已經(jīng)有關(guān)于并發(fā)錯誤特征/模式的研究[9,12]。在一般意義上，錯誤模式描述了在程序中可能發(fā)生的常見錯誤。一個bug模式是一個重復(fù)的相關(guān)的信號錯誤和潛在的bug在程序[29]。設(shè)計模式是常見問題的解決方案。確定地附加有否定結(jié)果的設(shè)計模式的解被稱為反模式。這是個術(shù)語，缺陷模式和反模式是非常相似的，其差別在于缺陷模式與編碼缺陷相關(guān)，而反模式與設(shè)計模式或架構(gòu)模式中的缺陷相關(guān)。在并發(fā)軟件測試的上下文中，錯誤模式和反模式可互換使用。例如，F(xiàn)indBugs工具在其bug模式列表中描述了許多設(shè)計模式[10]。同樣，Hallal et al也描述了。[12]描述了反模式庫中的幾個錯誤模式。在這項研究中，我們對bug模式和反模式使用“bug模式”這個術(shù)語。
3選擇工具和測試程序
3.1選擇Java靜態(tài)分析工具
我們選擇了4個Java靜態(tài)分析工具，如表1所示。在工具中，F(xiàn)indBugs和Jlint是文獻中討論最多的工具。然而，很少有文章[3,20]使用工具Coverity Prevent和Jtest。因此我們最好的知識沒有研究評估這兩個商業(yè)工具的Java多線程錯誤的有效性。 工具的簡要說明如下：
<v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"><v:stroke joinstyle="miter"><v:formulas></v:formulas><v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"></v:path></v:stroke></v:shapetype><v:shape id="圖片_x0020_1" o:spid="_x0000_i1027" type="#_x0000_t75" style="width:240.75pt;height:84pt;visibility:visible;mso-wrap-style:square"><v:imagedata src="file:///C:\Users\KAIFEN~1\AppData\Local\Temp\msohtmlclip1\01\clip_image001.png" o:title=""></v:imagedata></v:shape>
Coverity Prevent [3,4]是一種商業(yè)靜態(tài)分析工具，它結(jié)合統(tǒng)計和過程間分析與布爾可滿足性（SAT）來檢測缺陷。為了推斷正確的行為，它使用基于代碼中識別的行為模式的統(tǒng)計分析。然后跨方法，文件和模塊邊界進行跨程序（全程序）分析，以實現(xiàn)100％的路徑覆蓋。 SAT引擎和SAT求解程序確定路徑在運行時是否可行或?qū)е沦|(zhì)量，安全性或性能缺陷。除了Java，Coverity Prevent還支持C＃和C / C ++。Coverity Prevent檢測到多個多線程缺陷，如死鎖，線程塊，原子性和競態(tài)條件。
Coverity Prevent在多個平臺和編譯器上工作，如gcc，Microsoft Visual C ++等。它支持Eclipse和Visual Studio IDE。它還在產(chǎn)品設(shè)置（如搜索深度）上提供良好的可配置性?？梢酝ㄟ^創(chuàng)建自定義檢查器來擴展工具。
Jtest [15,20]是由Parasoft開發(fā)的商業(yè)靜態(tài)分析工具。它是用于自動化各種最佳實踐的集成解決方案。Parasoft Jtest支持各種代碼度量計算，編碼策略實施，靜態(tài)分析和Java的單元測試。它還為簡化的手動代碼審查過程和同行代碼審查提供支持。它執(zhí)行基于模式和流的靜態(tài)分析，以確保安全性和可靠性。Jtest有一個很好的檢查器檢測多線程錯誤的集合。
Jtest在Windows，Solaris，Linux和Mac OS X等多個平臺上工作。它具有GUI和命令行（批處理）支持。它適用于Eclipse，IBM RAD和Jbuilder。它允許使用圖形設(shè)計工具通過修改參數(shù)或提供展示示例規(guī)則違例的代碼來創(chuàng)建自定義規(guī)則。
FindBugs [13,14,20，]是在馬里蘭大學(xué)開發(fā)的一個基于開源錯誤模式的缺陷檢測器。它可以找到諸如解除引用空指針或未使用的變量的錯誤。它使用語法和數(shù)據(jù)流分析來檢查Java字節(jié)碼以檢測錯誤。FindBugs報告超過360種不同的bug模式。將錯誤模式分組為類別（例如，多線程正確性，正確性，性能等）。
FindBugs提供GUI和命令行界面。 除了它的swing界面，它適用于Eclipse和NetBeans。 FindBugs分析結(jié)果可以保存為XML。它需要JRE / JDK 1.5或更高版本。FindBugs是獨立于平臺的，它已知在Windows，GNU / Linux和MacOS X平臺上運行?？梢酝ㄟ^定義自定義檢測器來擴展FindBugs。
Jlint [1,20]是一個開源靜態(tài)分析工具，它執(zhí)行句法檢查，流分析，并構(gòu)建一個鎖圖，用于檢測繼承，同步等缺陷。它可以通過使用全局數(shù)據(jù)流分析來檢測數(shù)據(jù)競爭。它可以通過過程間和文件間分析來檢測死鎖。Jlint提供了多個檢查器來檢測多線程Java程序中的死鎖。Jlint檢測到大約36種不同類型的錯誤。它有一個名為AntiC的組件，它是一個C系列語言（即C，C ++，Objective C和Java）的語法檢查器。
Jlint有一個簡單的命令行界面。它運行在Windows，UNIX，Linux上。 Jlint不容易擴展。
3.2測試程序的選擇
我們選擇了包含并發(fā)性錯誤和錯誤模式的程序。有必要評估具有錯誤和錯誤模式的工具。 測試用于檢測錯誤的工具可以揭示工具的有效性。由于許多原因可能會出現(xiàn)錯誤。收集具有這么多種原因的現(xiàn)實生活中的Bug程序是相當具有挑戰(zhàn)性的，并且它需要大量的時間。 為此，測試工具與bug模式是重要的，因為bug模式可以反映出各種各樣的情況，其中bug可能發(fā)生[12]。 然而，錯誤模式并不總是錯誤，因此使用錯誤和錯誤模式測試工具是有意義的。
我們選擇了兩組程序，其中第一組表示并發(fā)錯誤，第二組表示錯誤模式。第一組程序取自并發(fā)錯誤基準套件[6,7]。有人批評使用基準來評估驗證和驗證技術(shù)的有效性，因為基準可能不完全涵蓋可能導(dǎo)致不正確結(jié)果的幾個因素[16]。 然而，如果考慮這些限制，可以使用基準[22]。
所選擇的基準也用于其他研究。基準的經(jīng)驗故事[8]報告了使用基準的14個研究和研究中心的列表。并行軟件測試專家和課程并發(fā)軟件測試的學(xué)生寫了大多數(shù)基準程序。我們從這個基準套件中選擇了19個程序，提供了一個精確的錯誤文檔和一個程序是由我們寫的。表2顯示了所選的基準程序。有關(guān)這些程序的詳細信息在附錄A中給出，更多詳細信息可在基準套件中找到。
<v:shape id="圖片_x0020_2" o:spid="_x0000_i1026" type="#_x0000_t75" style="width:291pt;height:276pt;visibility:visible;mso-wrap-style:square"><v:imagedata src="file:///C:\Users\KAIFEN~1\AppData\Local\Temp\msohtmlclip1\01\clip_image002.png" o:title=""></v:imagedata></v:shape>
第二組是Java多線程錯誤模式和反模式的集合。我們從3.1節(jié)討論的四個工具中收集了這些模式，Hallal等人[12]記錄了一系列反模式。我們已經(jīng)分類和識別了87個獨特的錯誤模式從141錯誤模式，在第4節(jié)討論。然后我們收集/寫了這些錯誤模式的程序。這些程序非常小; 通常10到30行代碼。
4 Bug模式分類
所選擇的工具有超過100個bug模式。為了進行實驗，我們需要識別獨特的bug模式。 更重要的是，我們需要在常見的詞匯表下分類這些錯誤模式。如果工具在修正的缺陷類別（例如死鎖，數(shù)據(jù)競爭，活鎖等）下描述其檢查器/規(guī)則/模式，則人可以容易地具有關(guān)于工具的強度的一般概念。表3示出了并發(fā)檢查器/錯誤模式的類別工具。
不幸的是，由工具分類的錯誤模式是不令人滿意的。只有Jlint在精細的類別級別描述其錯誤模式。在其他工具中，Jtest在工具提供的錯誤文檔中提供了其bug模式的進一步分類。Jtest描述了類別死鎖和競態(tài)條件中的19個bug模式，類別并發(fā)中的6個bug模式和其他18個bug模式未分類。應(yīng)該提到的是，Coverity Prevent描述的類別預(yù)覽下的五個跳格仍在細化，因此不推薦用于常規(guī)工業(yè)用途。
我們在文獻中發(fā)現(xiàn)了兩個主要作品[9,12]，它們與并發(fā)的bug模式一起工作。其中，Hallal等人[9]提到了具有良好的bug模式分類的優(yōu)點，并提出了對6種類型的38個并發(fā)反模式的全面分類。他們開發(fā)了保持開發(fā)者的利益的類別。我們采納并擴大了這些類別。為了開發(fā)一個獨特的bug模式集合，我們使用了141個bug模式，其中從模式中收集了103個模式，并從[9]開發(fā)的反模式庫中選擇了38個模式。 反模式庫記錄了來自FindBugs的8個bug模式和來自Jlint的11個bug模式。由于這個反模式庫主要包含并發(fā)錯誤模式，本研究使用術(shù)語“錯誤模式庫”來表示它。我們已經(jīng)從所選的103個錯誤模式中找到了87個獨特的錯誤模式，并對它們進行了分類，如表4所示。
在統(tǒng)一來自不同工具的錯誤模式時，我們發(fā)現(xiàn)了幾種情況，其中一個工具的錯誤模式檢測器被另一個工具部分地描述。例如，圖1所示的五個錯誤模式被標識為相似，因此被組合成單個組。Jtest錯誤模式描述了wait（），notify（）和notifyAll（）方法，F(xiàn)indBugs在兩個不同的bug模式中描述了wait（）和notify（）。 另一方面，Jlint只描述了wait（）。 FindBugs在單個檢查器下描述這兩個錯誤模式。以這種方式，由不同工具實現(xiàn)的錯誤模式檢測器可以在某種程度上從其他不同，盡管它們被列為常見的錯誤模式。然而，在一些情況下，在單個檢查器下描述的FindBugs錯誤模式分布在不同的組中。
5 實驗
我們遵循Wohlin等人提出的實驗過程 [27]。實驗被定義為：
從“開發(fā)源和商業(yè)工具測試多線程”的上下文中的“研究人員和從業(yè)者”的角度來分析“靜態(tài)分析工具”以用于“評估”關(guān)于它們的“缺陷檢測能力” Java程序“。
5.1實驗設(shè)計
5.1.1上下文選擇。
實驗離線，因為它不在真實的工業(yè)環(huán)境中執(zhí)行。實驗的主題是用于測試多線程Java程序的開源和商業(yè)靜態(tài)分析工具。實驗的對象是Java多線程程序的集合，這些程序?qū)⒂蓽y試工具進行分析。由于實驗的結(jié)果將有助于研究人員和從業(yè)者，因此實驗可以被表征為真實的。
5.1.2假設(shè)制定。
我們考慮了實驗的以下假設(shè)：
空假設(shè)H0：所選的靜態(tài)分析工具同樣能夠檢測Java多線程程序中的錯誤和錯誤模式。
備選假設(shè)H1：所選的靜態(tài)分析工具不能同等地檢測Java多線程程序中的錯誤和錯誤模式。
需要的措施：Java多線程錯誤，Java多線程錯誤模式，錯誤檢測能力。
5.1.3變量選擇
實驗的獨立變量是兩個“程序集”，即具有多線程錯誤的程序集和具有多線程錯誤模式的程序集。實驗的因變量是所選工具的缺陷檢測能力。缺陷檢測能力的兩種測量方法是缺陷檢測率和假陽性比率，計算公式如下：
<v:shape id="圖片_x0020_3" o:spid="_x0000_i1025" type="#_x0000_t75" style="width:381pt;height:97.5pt;visibility:visible;mso-wrap-style:square"><v:imagedata src="file:///C:\Users\KAIFEN~1\AppData\Local\Temp\msohtmlclip1\01\clip_image003.png" o:title=""></v:imagedata></v:shape>
5.1.4選擇主題
第2節(jié)討論的靜態(tài)分析工具是研究的主題。在開源軟件領(lǐng)域，所選的開源工具FindBugs [2,5,11-14,18,20,21,23-26,28]和Jlint [1,12,18,20,21,25,26 ，28]是學(xué)術(shù)界討論最多的工具。我們堅信它們代表著開源工具。雖然，用商業(yè)工具的研究不是很常見，它們的工業(yè)應(yīng)用[4,15]反映它們充分代表了商業(yè)靜態(tài)分析工具。
5.1.5實驗設(shè)計
在實驗中，所有主體（工具）將測試所有對象（程序集）。這里，自變量“程序集”是唯一的實驗因素。由于每個受試者將經(jīng)歷該因子的每一種可能的處理，因此實驗設(shè)計是完整的塊設(shè)計。表5示出了第一組程序的實驗設(shè)計。相同的設(shè)計應(yīng)用于第二組程序。
5.1.6儀器
我們將使用Eclipse（版本3.4.2）環(huán)境用于工具Coverity Prevent，F(xiàn)indBugs和Jtest，因為它們都為Eclipse提供插件。Jlint將在命令行模式下使用，因為它不提供圖形用戶界面。
在靜態(tài)分析工具中，我們將激活所有與多線程相關(guān)的檢查器/規(guī)則，并在完全分析模式下設(shè)置工具。 Coverity Prevent將同時應(yīng)用并發(fā)和預(yù)覽（檢查器的集合仍在開發(fā)中）檢查器。 Jtest結(jié)合了一組名為線程安全編程的規(guī)則，用于測試程序。在FindBugs中，多線程正確性“bug類別將使用最低優(yōu)先級報告級別為低，分析工作量為最大。Jlint將與+ all命令行選項一起使用。
實驗在Windows環(huán)境中執(zhí)行，在具有Intel?CoreTM2四核CPU和3GB主內(nèi)存的系統(tǒng)上。 JRE 1.6用作Java虛擬機，而MS Excel用于收集實驗數(shù)據(jù)。
5.1.7有效性評估
結(jié)論有效性。針對工具的并發(fā)檢查器/檢測器測試所選擇的程序。工具報告的警告記錄并仔細檢查。因此，結(jié)論有效性不被認為是至關(guān)重要的。
內(nèi)部和構(gòu)造有效性。所有選定的主題都是具有并發(fā)性錯誤檢測能力的Java靜態(tài)分析工具。所選受試者的分類和實驗的測量是直接的。在這兩個有效性類別中沒有觀察到顯著的威脅。
外部有效性。所選基準程序的平均大小是267行代碼，這是小的。在現(xiàn)實世界中，靜態(tài)分析器處理程序，甚至有數(shù)百萬行代碼。我們可以使用幾個中型到大型開源Java項目，而不是使用這些小的基準程序。然而，在我們在基準程序中發(fā)現(xiàn)的幾個項目中，不可能找到各種多線程錯誤。此外，對從這樣的程序產(chǎn)生的所有警告進行分類將是非常耗時的，因此實際上是不可能的。比較Java錯誤查找工具的研究[21]使用5個中等大小的開源項目，報告了從4個SA工具生成的9000多個并發(fā)警告。這項研究無法確定由于大量警告產(chǎn)生的假陽性和假陰性警告，這在文章的有效性部分的威脅中提到。
雖然基準程序覆蓋了各種并發(fā)錯誤，但它們并不是均勻分布在不同的類別中。表6顯示死鎖和活鎖類別中的錯誤的頻率分別為四和二。這些類別中的更大的錯誤樣本將使結(jié)果更一般化。每個類別中唯一選擇的錯誤模式的數(shù)量在尺寸和分布方面相當令人滿意，除了表4中所示的類別活鎖。
5.2實驗操作
作為實驗的準備，我們收集并組織了測試程序。第一組包含錯誤的程序是從基準中收集的。第二組中的程序（錯誤模式）是從不同的來源收集的。我們編寫/改進了第二套的幾個程序，因為它們既不可用也不完整。
實驗進行超過450人小時。對于每個程序，首先，我們讀取每個基準程序提供的程序描述。然后我們檢查代碼以識別程序中的錯誤。在檢查期間，我們發(fā)現(xiàn)很少有基準程序記錄的錯誤不是一個錯誤的情況。我們從錯誤列表中排除這種虛假記錄的錯誤。此外，我們發(fā)現(xiàn)了一些在基準文檔中沒有描述的錯誤。我們記錄了這些新的錯誤。然后我們用工具測試程序。我們記錄了工具生成的警告，并檢查每個警告，將其分為真或假警告。我們發(fā)現(xiàn)這些工具報告了大量的警告，這些警告就像關(guān)于不同編碼風(fēng)格和標準的一般警告。我們將它們歸類為一般警告。一個重要的事實是，基準程序中的所有錯誤都與多線程正確性有關(guān)。我們發(fā)現(xiàn)了這些工具報告的與軟件性能問題相關(guān)的幾個警告。我們已將這些警告記錄為一般警告。由于時間的限制，我們不能確定幾個警告為真或假，因此我們將它們標記為未決定。
為了根據(jù)bug模式來評估工具，我們針對從第4節(jié)中提到的bug模式的統(tǒng)一導(dǎo)出的87個獨特的bug模式進行了測試。對于bug模式程序，我們只檢查工具是否能夠檢測它。我們沒有進一步分析警告，以確定假陽性警告。這是因為，bug模式程序非常小，大多數(shù)情況下，他們?nèi)狈m當?shù)纳舷挛?，我們可以說一個已識別的模式是否作為一個bug。 因此，試圖識別錯誤模式的假陽性警告是無意義的。
6.分析和結(jié)果
6.1測試并發(fā)錯誤
我們測試了包含32個多線程錯誤的20個Java程序的SA工具。所有這些32個錯誤都與軟件正確性有關(guān)。然而，這些工具能夠檢測由bug模式測試探究的性能相關(guān)缺陷。表6顯示了所選SA工具檢測到的錯誤。所選的基準程序包含11種不同類型的錯誤。這些錯誤類型的詳細描述可在開發(fā)基準套件的研究人員所進行的研究[9]中找到。本文提供了一種并發(fā)錯誤的分類法作為一種bug模式。 然而，這些錯誤模式通常比工具實際實現(xiàn)的錯誤模式更高級別。 即使基準程序?qū)⑷毕菝枋鰹殄e誤模式，它們也是多線程錯誤。
在數(shù)據(jù)競爭和原子性違規(guī)類別中有26個錯誤，死鎖中有4個錯誤，活鎖類別中有2個錯誤。從表6，顯然Jtest是檢測數(shù)據(jù)種族和原子性錯誤的工具的贏家。在死鎖類別中，Jtest和Jlint都會檢測到4個缺陷。沒有一個工具可以檢測到弱現(xiàn)實（兩階段訪問），阻止關(guān)鍵段和孤立線程錯誤。 Coverity Prevent檢測到的所有5個錯誤屬于類別數(shù)據(jù)競爭和原子性違規(guī)。 FindBugs還檢測到5個錯誤，其中4個錯誤在數(shù)據(jù)競爭和原子性違反類別和死鎖類別中的1個錯誤。Jlint檢測到8個錯誤，這超過了Coverity Prevent和FindBugs。
我們已經(jīng)記錄并檢查了工具生成的每個警告。警告的概述如表7所示。一般警告類別包含那些與程序正確性不完全相關(guān)的警告。一般警告與軟件開發(fā)組織可能或可能不遵循的質(zhì)量和標準相關(guān)。這種警告的重要性因組織而異。
與其他工具相比，Jtest報告了大量警告，其中超過75％是一般警告。在136個一般警告中，從名為TRS.NAME的單個Jtest規(guī)則生成50個警告，用于檢查線程是否初始化其名稱。 Jtest規(guī)則TRS.SOUF報告23個警告，檢查是否使用非最終字段來同步代碼塊。 規(guī)則TRS.CIET生成另外22個警告，說不在一個不擴展Java Thread類的類中捕獲InterruptedException。另外22個警告來自規(guī)則TRS.STR，它檢查'this'引用是否用于同步代碼塊。這四個Jtest規(guī)則報告了117個警告，我們歸類為一般警告。
Jlint沒有質(zhì)量和樣式相關(guān)的并發(fā)規(guī)則，因此它沒有產(chǎn)生任何一般警告。Coverity Prevent有一個名為UNEXPECTED_SYNC的預(yù)覽檢查程序，它與性能問題相關(guān)。這個檢查器報告了5個警告，我們將其記錄為一般警告。有趣的是，F(xiàn)indBugs只報告了兩個一般警告，23個檢查器和40個錯誤模式，其中幾個錯誤模式解決質(zhì)量和樣式問題。
表8中顯示了唯一假陽性警報的數(shù)量以及工具的假陽性比率。 雖然，F(xiàn)indBugs和Coverity Prevent在假陽性比率中幾乎相同，F(xiàn)indBugs可以被認為是更好的，因為與Coverity Prevent相比，它檢查了大量的錯誤模式。以同樣的方式，Jtest和Jlint的假陽性比率是相同的，但是Jtest可以看作是更強大的，因為它檢查比Jlint更多的錯誤模式。
6.2。測試并發(fā)錯誤模式
我們使用工具測試了87個獨特的bug模式，如表3所示。預(yù)期每個工具都應(yīng)該能夠檢測到它聲稱檢測到的錯誤模式，反之亦然。工具幾乎能夠檢測到bug模式，如承諾。幾乎沒有觀察到工具不能檢測到它聲稱檢測到的錯誤模式的情況。在很少的情況下觀察到的錯誤模式檢測器的強度不同，盡管它們以相似的方式描述。
五個案例中，Coverity Prevent和Jlint未能檢測到錯誤模式，盡管他們有這些錯誤模式的檢測器。Coverity Prevent的跳棋是“違規(guī)”，“雙重鎖定”和“不安全laze初始化”，其中“被違規(guī)守衛(wèi)”是定期生產(chǎn)檢查。 Jlint的失敗bug模式檢測器是“方法名稱可以從不同的線程調(diào)用并且不同步”，以及“類的字段名稱”。與這些情況相反，Jlint錯誤模式“循環(huán)id：調(diào)用同步方法名稱可能導(dǎo)致死鎖”檢測Jtest描述的錯誤模式TRS.CSFS。但是，這兩個bug模式并不完全等同。Jlint的bug模式可以檢測鎖定圖的周期，這比Jtest的TRS.CSFS規(guī)則強得多。表9顯示了工具在不同類別中檢測到的錯誤模式數(shù)。
Jtest比其他工具在檢測bug方面要好得多。然而，它也比其他工具在生產(chǎn)警告方面處于領(lǐng)先地位。FindBugs和Coverity Prevent在檢測錯誤和報告假陽性警告方面幾乎相同。Jlint檢測到比FindBugs和Coverity Prevent更多的錯誤。但是，它還報告了最大數(shù)量的假陽性警告，如Jtest。Jtest檢測最大錯誤模式后跟FindBugs，Jlint檢測到比Coverity Prevent更多的錯誤。
總的來說，商業(yè)工具比開源工具在檢測Java并發(fā)錯誤和錯誤模式方面更好。然而，如果考慮假陽性警報的數(shù)量，則該區(qū)別不是非常重要。用戶需要在工具的錯誤檢測率和假陽性比率之間進行權(quán)衡以選擇適當?shù)墓ぞ?。如果檢查假陽性警告的成本小于早期缺陷檢測所節(jié)省的金額，那么Jtest應(yīng)該是最好的選擇。如果檢查更多的假陽性警告成本，則可以選擇FindBugs或Coverity Prevent。
用戶可以選擇從不同的工具選擇具體的錯誤檢測器。例如，Jlint提供的死鎖檢測器相當強。 然而，這并不意味著Jlint足以檢測死鎖錯誤。
對結(jié)果的有趣觀察反映了錯誤檢測的數(shù)量與工具報告的假陽性警告的數(shù)量之間的關(guān)系。 檢測更多錯誤的工具會產(chǎn)生更多的假陽性警告。然而，不進行進一步分析是否這一觀察總是真實的，因為它不包括本研究的范圍。
7討論
工具Jtest檢測到大約一半的多線程錯誤，事實是它產(chǎn)生大量的假陽性警告。Coverity Prevent工具從假陽性警告的角度來看是有希望的，但是這個工具在檢測故障方面相當弱。一個原因可能是在所選擇的工具中由該工具呈現(xiàn)的并發(fā)錯誤檢測器的最小數(shù)目。我們發(fā)現(xiàn)，開源工具FindBugs和Jlint檢測到不同的缺陷，因此它們應(yīng)該組合使用。
雖然Jlint產(chǎn)生大量的假陽性警告，并且Jlint的命令行用戶界面不是用戶友好的，強烈建議除了任何其他工具之外使用Jlint的死鎖檢測器。我們發(fā)現(xiàn)Jlint的死鎖檢測器在檢測錯誤方面相當強大，并且它們報告的錯誤肯定警告少于競態(tài)條件檢測器。我們已經(jīng)確定Jlint多次報告類似的警告。將這樣的警告分組為單個警告將減少報告的警告的數(shù)量，這將既節(jié)省時間并增加該工具的可用性。
FindBugs提供了一個簡單靈活的GUI界面，作為eclipse插件和獨立的swing界面。 FindBugs有一組豐富的錯誤模式檢測器，它報告很少的假陽性警告。雖然FindBugs發(fā)現(xiàn)了很少的并發(fā)性錯誤，但Coverity Prevent用戶應(yīng)該使用它，因為它識別了不同的Bug，而不是Coverity Prevent。
Jtest用戶應(yīng)該在使用它們之前檢查探測器，特別是在“一般警告/錯誤”和“質(zhì)量和風(fēng)格問題”類別中的警告，因為一些探測器可能產(chǎn)生大量的一般警告。
FindBugs和Coverity Prevent顯示某些檢測器的事件列表，這些檢測器在檢查相應(yīng)的警告時非常有用。 Jlint重復(fù)地為這些檢測器生成警告，其中Jtest僅報告關(guān)于缺陷的單個警告，而沒有進一步的細節(jié)。這將是很容易理解它與一個例子。讓我們假設(shè)在方法的三個位置使用共享字段而不被鎖定。 FindBugs和Coverity Prevent都將報告一個警告，其中包含三個事件的詳細信息，其中字段被訪問而不被鎖定。 Jlint將報告3個不同的警告，Jtest將報告一個警告，而不包含三個訪問的詳細信息。
FindBugs的swing界面提供了一個非常靈活的界面，以自定義的方式查看報告的警告。 Jtest還提供了報告警告的良好視圖。它按類別，然后按優(yōu)先級，然后按規(guī)則分組警告。因此，用戶只能看到由特定規(guī)則生成的所有警告或在特定優(yōu)先級下警告的所有規(guī)則。
我們已經(jīng)識別了由表7中所示的工具報告的大量一般警告。如果在必要時使用它們，則可以跳過這些一般警告。為此，規(guī)則/檢查器/錯誤模式需要在使用前根據(jù)某個項目的標準進行審查。
在檢查基準程序時花了相當多的時間。所選的基準程序?qū)崿F(xiàn)某些并發(fā)錯誤。然而，在檢查源代碼時，我們發(fā)現(xiàn)了幾個并發(fā)缺陷，這些缺陷在可用的基準文檔中沒有討論。然而，可用的錯誤文檔并沒有提到在程序中可能有額外的并發(fā)錯誤。如果基準測試用戶完全依賴于基準測試程序中存在的錯誤，可能會導(dǎo)致不正確的錯誤檢測率和假陽性比率。我們在從基準套件中選擇的程序中發(fā)現(xiàn)了11個新的并發(fā)性錯誤，如附錄A所示。
我們強烈建議對SA工具的錯誤模式檢測器進行更嚴格的分類。這將有助于用戶更容易地學(xué)習(xí)和審查錯誤模式檢測器。對工具報告的警告的分析表明，從幾個數(shù)量的錯誤模式檢測器產(chǎn)生了大量的一般警告。精細的分類法將幫助用戶識別對于某個軟件項目的標準不是很必要或關(guān)鍵的這種檢測器。
雖然靜態(tài)分析工具報告假陽性警告，但它們可以用于檢測并發(fā)缺陷。工具的平均缺陷檢測率為0.25，這與缺陷的早期檢測在軟件開發(fā)的成本降低中是至關(guān)重要的問題的事實不難理解。
8相關(guān)工作
C. Artho [1]評估了三個動態(tài)（MaC，Rivet，Visualthreads）和兩個SA分析工具（Jlint和ESC / Java），用于在Java程序中查找多線程錯誤。研究結(jié)果表明，沒有一個工具是明確的贏家。這項研究的一個主要部分是關(guān)于擴展Jlint工具。
一項研究[21]使用五個Bug查找工具，即Bandera，ESC / Java 2，F(xiàn)indBugs，Jlint和PMD來交叉檢查他們的錯誤報告和警告。這項研究確定了工具報告的重疊警告。他們將警告分成不同的bug類別，其中并發(fā)性被標識為類別之一。最后，提出了一個元工具，它結(jié)合了所使用的所有五個工具的警告。
在上面討論的兩個研究中，第一個研究工作檢測并發(fā)性錯誤，第二個研究使用并發(fā)性作為一個問題。然而，我們發(fā)現(xiàn)幾個研究從不同的角度評估靜態(tài)分析工具，而不是檢測并發(fā)性錯誤。這些研究在下面討論。
C. N. Christopher [5]評估了四個具有理想框架的SA框架。 評估結(jié)果表明，沒有框架是理想的。然而，F(xiàn)indBugs和Soot比PMD和Crystal相對更好。評價的重點是框架的可用性，而不是工具。
一項研究[20]評估了四個商業(yè)和七個開源SA工具。本研究還推薦了六個步驟的方法來評估軟件的質(zhì)量。
兩個工業(yè)案例研究結(jié)果在[23]中描述，其中兩個SA錯誤模式工具，F(xiàn)indBugs和PMD應(yīng)用于評估。然而，這項研究沒有討論任何并發(fā)問題。另一個工業(yè)案例研究[24]分析了錯誤發(fā)現(xiàn)工具測試和檢查的相互關(guān)系。研究表明，測試工具檢測更多缺陷，但工具不檢測通過檢查發(fā)現(xiàn)的一些缺陷。因此，結(jié)合這兩種測試是很好的。
另一項研究[25]比較了八個SA工具來檢測Java中的安全編碼啟發(fā)式違反。這些工具確定了115種不同的違反安全編碼試探法的方法，并開發(fā)了一種能使理解更容易應(yīng)用的分類法。
F. Wedyan et al[26]評估自動化SA工具的Java程序的有用性。他們評估SA工具檢測缺陷和識別代碼重構(gòu)修改的有效性。
9結(jié)論
我們已經(jīng)評估了用于檢測Java多線程錯誤和錯誤模式的靜態(tài)分析工具。使用一組包含并發(fā)性錯誤和一組錯誤模式的基準程序來執(zhí)行實驗。我們檢查了工具報告的每個警告，測試基準程序，并將其分為真實或假陽性警告。從工具和反模式庫中收集了總共141個錯誤模式。我們確定了87個獨特的錯誤模式，并針對他們測試了工具。此外，我們分類所有的bug模式，這將幫助用戶快速學(xué)習(xí)和審查由工具實現(xiàn)的錯誤模式檢測器。
工具Jtest的缺陷檢測率為0.47，其中工具的平均缺陷檢測率為0.25。這揭示了單獨的靜態(tài)分析工具不足以檢測并發(fā)性錯誤的事實。此外，工具報告了假陽性警告，這與檢測到的缺陷數(shù)量大致相同。然而，使用這些工具早期檢測缺陷是一個好主意。對錯誤模式的實驗表明，所選擇的工具能夠檢測大范圍的錯誤模式?？偟膩碚f，商業(yè)工具比開源工具更好。然而，這些工具的有效性在檢測不同類別中的錯誤和報告假陽性警告方面有所不同。如果用戶利用多個工具來檢測不同類別中的錯誤，這將是更有利的。
記錄的bug模式可能在它們之間具有沖突和依賴性。一些工具排列了錯誤檢查器，具有不同的優(yōu)先級。然而，這項研究沒有考慮bug模式的優(yōu)先級。未來的工作是可能的，以識別沖突，依賴性和bug模式的優(yōu)先級。
10參考書
[1] C. Artho, “Finding faults in multi-threaded programs,” Master's thesis, Institute of Computer Systems, Federal Institute of Technology, Zurich/Austin, 2001.
[2] N. Ayewah, W. Pugh, J.D. Morgenthaler, J. Penix, and Y. Zhou, “Evaluating static analysis defect warnings on production software,” 7th ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering, June 13, 2007 - June 14, 2007, San Diego, CA, United states: Association for Computing Machinery, 2007, pp. 1-7.
[3] D. Baca, B. Carlsson, and L. Lundberg, “Evaluating the cost reduction of static code analysis for software security,” 3rd ACM SIGPLAN Workshop on Programming Languages and Analysis for Security 2008, PLAS'08, June 8, 2008 - June 8, 2008, Tucson, AZ, United states: Association for Computing Machinery, 2008, pp. 79-88.
[4] Coverity Prevent. [online]. Viewed 2009 august 13. Available: http://www.coverity.com/products/coverityprevent.html
[5] C.N. Christopher, “Evaluating Static Analysis Frameworks,” Carnegie Mellon University Analysis of Software Artifacts, 2006.
[6] Y. Eytani, K. Havelund, S. Stoller, and S. Ur, “Towards a framework and a benchmark for testing tools for multi-threaded programs,” Concurrency and Computation Practice & Experience, vol. 19, Mar. 2007, pp. 267-79.
[7] Y. Eytani, K. Havelund, S. Stoller, and S. Ur, “Toward a benchmark for multi-threaded testing tools,” Concurrency and Computation: Practice and Experience, 2005.
[8] Y. Eytani, R. Tzoref, and S. Ur, “Experience with a concurrency bugs benchmark,” 2008 IEEE International Conference on Software Testing Verification and Validation Workshop (ICSTW), 9-11 April 2008, Piscataway, NJ, USA: IEEE, 2008, pp. 379-84.
[9] E. Farchi, Y. Nir, and S. Ur, “Concurrent bug patterns and how to test them,” Los Alamitos, CA, USA: IEEE Comput. Soc, 2003, p. 7 pp.
[10] FindBugs Bug Description. [online]. Viewed 2009 august 13. Available: http://findbugs.sourceforge.net/bugDescriptions.html
[11] J.S. Foster, M.W. Hicks, and W. Pugh, “Improving software quality with static analysis,” 7th ACM SIGPLANSIGSOFT Workshop on Program Analysis for Software Tools and Engineering, June 13, 2007 - June 14, 2007, San Diego, CA, United states: Association for Computing Machinery, 2007, pp. 83-84.
[12] H. Hallal, E. Alikacem, W. Tunney, S. Boroday, and A. Petrenko, “Antipattern-based detection of deficiencies in Java multithreaded software,” Proceedings. Fourth International Conference on Quality Software, 8-9 Sept. 2004, Los Alamitos, CA, USA: IEEE Comput. Soc, 2004, pp. 258-67.
[13] D. Hovemeyer and W. Pugh, “Finding concurrency bugs in Java,” Proceedings of the PODC Workshop on Concurrency and Synchronization in Java Programs, St. John's, Newfoundland, Canada, 2004.
[14] D. Hovemeyer and W. Pugh, “Finding bugs is easy,” ACM SIGPLAN Notices, vol. 39, 2004, pp. 92-106.
[15] Java testing tools: Static code analysis, code review, unit testing. [online]. Viewed 2009 august 13. Available: http://www.parasoft.com/jsp/products/home.jsp?product=Jtest
[16] B.A. Kitchenham, “The case against software benchmarking, keynote lecture,” Proceedings of The European Software Measurement Conference (FESMA-DASMA 2001), Heidelberg, May 2001, pp 1–9.
[17] S. Lipner, The Trustworthy Computing Security Development Life Cycle, Proceedings of the 20th Annual Computer Security Applications Conference (ACSAC’o4), p.213, 2004.
[18] B. Long, P. Strooper, and L. Wildman, “A method for verifying concurrent Java components based on an analysis of concurrency failures,” Concurrency and Computation Practice & Experience, vol. 19, Mar. 2007, pp. 281-94.
[19] N. Nagappan and T. Ball, “Static analysis tools as early indicators of pre-release defect density,” 27th International Conference on Software Engineering, ICSE 2005, May 15, 2005 - May 21, 2005, Saint Louis, MO, United states: Institute of Electrical and Electronics Engineers Computer Society, 2005, pp. 580-586.
[20] F. Painchaud and R. Carbone, Java software verification tools: Evaluation and recommended methodology, Technical Memorandum. Defence R&D Canada. Document No. TM 2005226. March 2006. http://cradpdf.drdc.gc.ca/PDFS/unc57/p527369.pdf
[21] N. Rutar, C.B. Almazan, and J.S. Foster, “A comparison of bug finding tools for Java,” ISSRE 2004 Proceedings; 15th International Symposium on Software Reliability Engineering, November 2, 2004 - November 5, 2004, Saint-Malo, France: IEEE Computer Society, 2004, pp. 245-256.
[22] W.F. Tichy, “Should computer scientists experiment more?,” Computer, vol. 31, 1998, pp. 32-40.
[23] S. Wagner, F. Deissenboeck, M. Aichner, J. Wimmer, and M. Schwalb, “An evaluation of two bug pattern tools for Java,” 2008 First IEEE International Conference on Software Testing, Verification and Validation (ICST '08), 9-11 April 2008, Piscataway, NJ, USA: IEEE, 2008, pp. 248-57.
[24] S. Wagner, J. Jurjens, C. Roller, and P. Trischberger, “Comparing Bug finding tools with reviews and tests,” Testing of Communicating Systems. 17th IFIP TC6/WG 6.1 International Conference TestCom 2005. Proceedings, 31 May2 June 2005, Berlin, Germany: Springer-Verlag, 2005, pp. 4055.
[25] M.S. Ware and C.J. Fox, “Securing Java code: heuristics and an evaluation of static analysis tools,” Proceedings of the 2008 workshop on Static analysis, Tucson, Arizona: ACM, 2008, pp. 12-21.
[26] F. Wedyan, D. Alrmuny, and J. Bieman, “The effectiveness of automated static analysis tools for fault detection and refactoring prediction,” 2009 2nd International Conference on Software Testing Verification and Validation (ICST 2009), 1-4 April 2009, Piscataway, NJ, USA: IEEE, 2009, pp. 141-50.
[27] C. Wohlin, P. Runeson, M. Host, M. C. Ohlsson, B. Regnell and A. Wesslen, Experimentation in Software Engineering:An Introduction, Kluwer Academic Publishers, 2000.
[28] M.A. Wojcicki and P. Strooper, “Maximising the information gained from a study of static analysis technologies for concurrent software,” Empirical Software Engineering, vol. 12, 2007, pp. 617-645.
[29] L. Yu, J. Zhou, Y. Yi, P. Li, and Q. Wang, “Ontology Model-Based Static Analysis on Java Programs,” Proceedings of the 32nd Annual IEEE International Computer Software and Applications Conference-Volume 00, IEEE Computer Society Washington, DC, USA, 2008, pp. 92-99.
說明：還有幾個附錄，中間主要講述了詳細的錯誤的分類。
