1、畢業(yè)設(shè)計(jì)外文資料翻譯學(xué) 院： 專業(yè)班級： 學(xué)生姓名： 學(xué) 號： 指導(dǎo)教師： 外文出處：Gustavo Pinto,Weslley Torres,Benito Fernandes,Fernando Castor,Roberto S.M.Barros.Journalof Syatem and SoftwareJ. ELSEVIER,2015,Volume 106:Pages 59-81 附 件：1.外文資料翻譯譯文； 2.外文原文 指導(dǎo)教師評語：該同學(xué)的英文專業(yè)資料術(shù)語翻譯較準(zhǔn)確，體現(xiàn)了一定的專業(yè)英語水平。翻譯材料能夠與原文保持一致，能正確表達(dá)出原文意思。翻譯字、詞數(shù)滿足要求。翻譯材料的格式符合要

2、求。該同學(xué)較好的完成了外文文獻(xiàn)翻譯工作。簽名： 年 月 日第 第 頁，共21頁外文資料翻譯譯文使用Java的并發(fā)編程結(jié)構(gòu)的大規(guī)模研究1介紹多核系統(tǒng)提供潛在的廉價(jià)、可擴(kuò)展、高性能計(jì)算并且在能源消耗上有顯著減少。為了實(shí)現(xiàn)這一潛力,有必要利用包括多個(gè)處理元素的集合的新的異構(gòu)體系結(jié)構(gòu)。利用多核的技術(shù),應(yīng)用程序必須并發(fā),構(gòu)這成了挑戰(zhàn),因?yàn)楸娝苤?并發(fā)編程的困難(Sutter,2005)。許多編程語言提供并發(fā)編程的構(gòu)造。這些解決方案在抽象,error-proneness和性能方面有很大區(qū)別。當(dāng)涉及到并發(fā)編程結(jié)構(gòu)時(shí)Java編程語言尤其豐富。例如,它包括監(jiān)控的概念,一個(gè)支持要互斥和同步的低級的機(jī)制,以及高層

3、圖書館(Lea，2005),java.util。同時(shí),也稱為j.u.c,在版本1.5語言中引入的。在學(xué)術(shù)界和工業(yè),有一種強(qiáng)烈的信念,多核技術(shù)將從根本上改變構(gòu)建軟件的方式。然而,據(jù)我們所知,就開發(fā)人員使用的結(jié)構(gòu)來說，關(guān)于并發(fā)軟件發(fā)展實(shí)踐的當(dāng)前狀態(tài)是缺乏可靠的信息的。在這項(xiàng)工作中,我們的目標(biāo)是部分填補(bǔ)這個(gè)空白。具體來說,我們提供了一個(gè)實(shí)證研究,旨在在Java應(yīng)用程序中建立并發(fā)編程構(gòu)造的實(shí)際使用的當(dāng)前狀態(tài)。我們分析了2227個(gè)穩(wěn)定和成熟的Java項(xiàng)目包括超過來自SourceForge(LoC-沒有空行和注釋)的6億行代碼,其中一個(gè)是最流行的開放源代碼存儲庫。我們的分析包括了這些應(yīng)用程序幾個(gè)版本和基于

4、50多個(gè)自動收集的源代碼指標(biāo)。我們也研究這些指標(biāo)之間的相關(guān)性,試圖找到并發(fā)編程結(jié)構(gòu)的使用趨勢。我們選擇了Java,因?yàn)樗且粋€(gè)廣泛使用的面向?qū)ο蟮木幊陶Z言。此外,正如我們之前所說,它包括對有低級和高級機(jī)制的多線程的支持。此外,它是在SourceForge數(shù)量最高的項(xiàng)目的語言。如何編寫并行程序的證據(jù)可以提高開發(fā)人員對于可用機(jī)制的意識。它還可以顯示如何讓廣為接受的一些機(jī)制投入實(shí)踐。此外,它可以告訴設(shè)計(jì)新的機(jī)制的研究人員關(guān)于開發(fā)人員可能更愿意使用的種類結(jié)構(gòu)。工具廠商也可以通過支持使用鮮為人知的和更有效的機(jī)制的開發(fā)人員受益,例如,通過實(shí)現(xiàn)重構(gòu)( HYPERLINK /science/article/p

5、ii/S0164121215000849 l bib0006 Dig, Marrero, Ernst, 2009, HYPERLINK /science/article/pii/S0164121215000849 l bib0016 Ishizaki, Daijavad, Nakatani, 2011and HYPERLINK /science/article/pii/S0164121215000849 l bib0036 Schfer, Sridharan, Dolby, Tip, 2011a)。此外,本研究結(jié)果發(fā)現(xiàn)學(xué)生進(jìn)入教師的并發(fā)編程的重要性更令人信服,這不僅是對軟件開發(fā)的未來,而且還對

6、當(dāng)下?；讷@得的數(shù)據(jù),我們建議回答的研究問題(RQ)。1.1RQ1:Java應(yīng)用程序使用并發(fā)編程結(jié)構(gòu)嗎?我們發(fā)現(xiàn)超過75%的最新版本的檢查項(xiàng)目包括某種形式的并發(fā)編程,如,至少有一個(gè)同步關(guān)鍵字的出現(xiàn)。在媒介項(xiàng)目中(20001 - 100000 LoC)，對于大型項(xiàng)目，這個(gè)百分比的增長超過90%,達(dá)到100%(超過100000 LoC)。此外,平均數(shù)字(每100000 LoC)的同步方法,類擴(kuò)展線和類實(shí)現(xiàn)運(yùn)行,分別66.75,13,13.85。這些結(jié)果表明,項(xiàng)目經(jīng)常使用并發(fā)編程構(gòu)造并且數(shù)量相當(dāng)密集。另一方面也許相反,盡管多核機(jī)器普遍，這些年來并發(fā)項(xiàng)目的總百分比未見顯著改變。1.2RQ2:開發(fā)人員有

7、轉(zhuǎn)移到基于library的并發(fā)性嗎?我們的數(shù)據(jù)表明,只有23.21%的分析并發(fā)采用java.util并發(fā)庫里的項(xiàng)目類。另一方面,這個(gè)庫在采用上有增長。然而,這種增長似乎并不是一般有關(guān)Java的傳統(tǒng)的并發(fā)編程結(jié)構(gòu)的使用減少,有一些例外。此外,最近在積極開發(fā)更多的項(xiàng)目,例如,自2009年以來至少有一個(gè)版本采用java.util并發(fā)庫發(fā)布。因此,使用library的成熟的項(xiàng)目有活躍的百分比,高于23.21%。1.3RQ3:開發(fā)人員如何從并發(fā)線程中保護(hù)共享變量?大多數(shù)的項(xiàng)目使用同步塊和方法。揮發(fā)性修飾符,顯式鎖(包括讀寫鎖等變化)和原子變量是不太常見的,盡管它們中的一些似乎越來越受歡迎。我們還注意到同

8、步塊使用的一個(gè)趨勢的增長。1.4RQ4:開發(fā)人員仍然使用java.lang線程類來創(chuàng)建和管理線程?我們發(fā)現(xiàn)實(shí)現(xiàn)Runnable接口是定義新線程的最常見的方法。此外,相當(dāng)數(shù)量的項(xiàng)目采用執(zhí)行人管理線程執(zhí)行(11.14%的并發(fā)項(xiàng)目)?？梢杂^察到的項(xiàng)目采用執(zhí)行人展覽疲軟趨勢來減少顯式擴(kuò)展的線程類的數(shù)量。1.5RQ5:開發(fā)人員使用線程安全的數(shù)據(jù)結(jié)構(gòu)?我們發(fā)現(xiàn)開發(fā)人員仍然使用Hashtable和HashMap,盡管前者是線程安全的但效率低下,后者不是線程安全的。盡管如此,在許多項(xiàng)目中，有使用ConcurrentHashMap代替其他關(guān)聯(lián)數(shù)據(jù)結(jié)構(gòu)的趨勢。1.6RQ6:開發(fā)者使用狀態(tài)同步多長時(shí)間呢?大量的并發(fā)

9、項(xiàng)目包括notify的調(diào)用方法,notifyAll或wait方法等。同時(shí),我們注意到一個(gè)小數(shù)量的項(xiàng)目已經(jīng)消除了這些方法的許多用法,采用CountDownLatch類,java.util并發(fā)庫的一部分。這個(gè)數(shù)字對統(tǒng)計(jì)分析來說是不足夠大的。然而,它表明有著簡單語義的機(jī)制像CountDownLatch有潛力,在某些情況下,替代低級,更傳統(tǒng)化。1.7RQ7:開發(fā)人員試圖捕獲可能會導(dǎo)致突然的線程失敗的異常?我們的數(shù)據(jù)表明,只有不到3%的并發(fā)項(xiàng)目執(zhí)行線程。沒有獲取異常的處理界面,這意味著,在97%的并發(fā)項(xiàng)目中,源于一個(gè)編程錯(cuò)誤的異常可能導(dǎo)致線程靜靜地死去,潛在的影響與它們進(jìn)行交互線程的行為。此外,分析這些

10、實(shí)現(xiàn),我們發(fā)現(xiàn)即使他們實(shí)現(xiàn)一個(gè)處理程序時(shí)，開發(fā)人員常常不知道如何處理未捕獲的異常的線程。這提供了一些跡象，表明新的異常處理機(jī)制是明確解決并發(fā)應(yīng)用程序需要的。提供一個(gè)基本的直覺，開發(fā)者相信是真實(shí)的并發(fā)編程結(jié)構(gòu)的用法,我們還進(jìn)行了一項(xiàng)調(diào)查,包含了160多名軟件開發(fā)人員。這些開發(fā)人員都是對源代碼進(jìn)行分析的項(xiàng)目的提交者。這個(gè)調(diào)查中受訪者提出各種問題,比如“你認(rèn)為哪個(gè)是最經(jīng)常使用并發(fā)/并行編程構(gòu)造Java語言的?”。在本文,我們通過分析Java源代碼對比調(diào)查結(jié)果與數(shù)據(jù)。這項(xiàng)工作做出了以下貢獻(xiàn):它是在Java語言中，并發(fā)編程結(jié)構(gòu)的用法上第一個(gè)大規(guī)模研究,包括如何使 用這些構(gòu)造的分析以已經(jīng)在隨著時(shí)間演變。它

11、提供了大量的數(shù)據(jù)與當(dāng)前實(shí)踐狀態(tài)的真正的并行項(xiàng)目,這些項(xiàng)目隨著時(shí) 間演變。它展示了提交者做出的調(diào)查結(jié)果的一些項(xiàng)目分析。本調(diào)查概述了開發(fā)人員 關(guān)于使用并發(fā)編程結(jié)構(gòu)的感知。剩下的文章組織如下:第二節(jié)介紹一些在Java方面的并發(fā)編程的背景知識。第三節(jié)描述了我們的調(diào)查設(shè)置和一些初步結(jié)果。接下來,在第四節(jié)中,我們描述了我們用來下載并提取分析數(shù)據(jù)的基礎(chǔ)設(shè)施。在第五節(jié)就研究問題來說，我們提出了研究結(jié)果。然后我們在第六節(jié)里提出了線程對工作的有效性，在第七節(jié)提出了一些影響。第8節(jié)致力于相關(guān)工作。最后,在9節(jié),我們提出我們的結(jié)論和討論未來的發(fā)展方向。2.背景之前我們的研究中,我們提供了一個(gè)并發(fā)編程的簡短的背景。關(guān)于

12、并發(fā)編程概念的詳細(xì)介紹可用其他地方(Tanenbaum,2008)。一般來說,進(jìn)程和線程是并發(fā)編程的主要的抽象。一個(gè)過程是一個(gè)容器,持續(xù)運(yùn)行一個(gè)程序需要的所有信息,例如,進(jìn)程的內(nèi)存位置可以讀取和寫入數(shù)據(jù)。一個(gè)線程,另一方面,可以被看作是一個(gè)輕量級的過程。有不同的實(shí)現(xiàn),即使線程線程和進(jìn)程不同于彼此,多個(gè)線程可以存在在同一個(gè)進(jìn)程和共享自己的數(shù)據(jù),在不同的進(jìn)程不共享資源。此外,線程可以共享源代碼信息。這個(gè)特性是把雙刃劍,因?yàn)樗兄l(fā)bug的成本例如競爭條件。然而,使用線程的一個(gè)主要原因是,因?yàn)橐驗(yàn)榫€程沒有相關(guān)資源，他們比進(jìn)程更容易和更快。例如,創(chuàng)建一個(gè)線程比創(chuàng)建一個(gè)進(jìn)程可以快100倍(Tanen

13、baum,2008)。在一個(gè)處理器,多線程通常發(fā)生在時(shí)分多路復(fù)用。換句話說,處理器在不同線程之間切換。這個(gè)上下文切換通常發(fā)生快速和線程同時(shí)運(yùn)行的最終用戶感知。在多處理器或在多核系統(tǒng)中,或任務(wù)的線程會同時(shí)運(yùn)行,每個(gè)處理器或核心運(yùn)行一個(gè)特定的線程。同時(shí)運(yùn)行的線程數(shù)量是有限的可用的處理器數(shù)量。在過去的十年，并發(fā)編程一直是一個(gè)令人興奮的研究領(lǐng)域。盡管沒有共識出并發(fā)性的一個(gè)單個(gè)模型,隨著各種競爭模型的發(fā)展，許多進(jìn)步一直在出現(xiàn)( HYPERLINK /science/article/pii/S0164121215000849 l bib0002 Burckhardt, Baldassin, Leijen,

14、 2010和 HYPERLINK /science/article/pii/S0164121215000849 l bib0043 Yi, Sadowski, Flanagan, 2011)。除此之外,無論并發(fā)性的模型,許多研究人員( HYPERLINK /science/article/pii/S0164121215000849 l bib0006 Dig, Marrero, Ernst, 2009, HYPERLINK /science/article/pii/S0164121215000849 l bib0011 Goetz, Peierls, Bloch, Bowbeer, Holme

15、s, Lea, 2006, HYPERLINK /science/article/pii/S0164121215000849 l bib0016 Ishizaki, Daijavad, Nakatani, 2011和 HYPERLINK /science/article/pii/S0164121215000849 l bib0028 Okur, Dig, 2012)認(rèn)為,高并發(fā)庫可以提高軟件質(zhì)量。java.util并發(fā)庫旨在簡化并發(fā)應(yīng)用程序在Java語言的發(fā)展。使用這個(gè)框架,甚至是一個(gè)缺乏經(jīng)驗(yàn)的程序員也可以編寫并發(fā)應(yīng)用程序工作。java.util并發(fā)庫提供了一些特性來簡化并發(fā)編程的任務(wù)。此外,

16、library是優(yōu)化性能。下面我們討論一些最知名的結(jié)構(gòu)。我們假設(shè)讀者熟悉Java編程語言和并發(fā)編程的基本概念,如鎖,相互排斥和同步。java.util并發(fā)庫包含一些構(gòu)造,如信號量和交換機(jī),我們不討論本文,因?yàn)樗麄兒苌偈褂谩＠?我們發(fā)現(xiàn)信號量類從未用于分析項(xiàng)目。鎖:鎖接口的實(shí)現(xiàn),如ReentrantLock,比可以使用同步的方法和代碼塊執(zhí)行支持更靈活的鎖。他們促進(jìn)更多的通用結(jié)構(gòu),可能有不同的取決于線程訪問數(shù)據(jù)的屬性,并可能支持多個(gè)相關(guān)條件(一個(gè)接口定義與鎖相關(guān)的條件變量)對象。鎖是一種工具,用于控制由多個(gè)線程訪問共享資源。一般來說,一個(gè)鎖提供了獨(dú)家訪問共享資源: 一次只有一個(gè)線程可以獲得鎖,每

17、個(gè)訪問共享資源首先要求鎖被收購。然而,一些鎖允許并發(fā)訪問共享資源,如ReadWriteLock的讀鎖。鎖的實(shí)現(xiàn)在使用同步方法和通過支持阻塞的塊嘗試獲取鎖(tryLock()上提供額外的功能塊,并嘗試獲取被打斷的鎖。原子數(shù)據(jù)類型：這些數(shù)據(jù)類型被一個(gè)支持無鎖的小工具箱的類提供,在單一變量上線程安全編程。從本質(zhì)上講,這類java . util . concurrent原子包擴(kuò)展了波動值的概念,字段,和數(shù)組元素,提供一個(gè)原子有條件的使用compareAndSet()方法更新操作。如果其當(dāng)前值等于方法的第一個(gè)參數(shù)，該方法自動設(shè)置一個(gè)變量,成功返回true值。在這個(gè)包中包含的類方法無條件地獲取和設(shè)置值,與

18、遞增和遞減變量的值。該包中的類的例子AtomicBoolean,AtomicInteger AtomicIntegerArray。并發(fā)集合:一組集合決定在多線程環(huán)境中使用。這組包括ConcurrentHashMap，CopyOnWriteArrayList，CopyOnWriteArraySet和ArrayBlockingQueue。在這個(gè)包中并行前綴用于某些類是一個(gè)速記，指示一些區(qū)別類似同步的類,它使用一個(gè)鎖的整個(gè)集合。例如類Hashtable和collections . synchronizedmap()是同步的,但是ConcurrentHashMap“并發(fā)”。并發(fā)集合是線程安全的,但并不

19、是由一個(gè)單一的鎖治理。特別是ConcurrentHashMap,安全地允許任意數(shù)量的并發(fā)讀取以及可調(diào)并發(fā)寫道。同步:java.util同時(shí)提供了一些類,可以取代wait()和notify()方法。CountDownLatch是一個(gè)同步的援助,允許一個(gè)或多個(gè)線程等待直到其他線程正在執(zhí)行的一組操作都已完成。CountDownLatch等待多個(gè)線程結(jié)束之前讓他們繼續(xù)下去。CyclicBarrier是另一個(gè)同步的援助。它允許一組線程等待以對方達(dá)到一個(gè)共同的障礙點(diǎn)。執(zhí)行人:執(zhí)行人,被sub-interfaces Executor接口及其實(shí)現(xiàn)體現(xiàn)出來,支持多個(gè)方法來管理線程執(zhí)行。他們提供了一個(gè)異步任務(wù)執(zhí)行

20、框架。ExecutorService管理隊(duì)列和任務(wù)的調(diào)度,并允許控制關(guān)閉。ExecutorService接口及其實(shí)現(xiàn)提供方法來異步地執(zhí)行一個(gè)表示為可調(diào)用的任何函數(shù),可運(yùn)行的result-bearing模擬。ScheduledExecutorService子接口添加支持延遲和執(zhí)行周期性任務(wù)。未來的一個(gè)函數(shù),返回結(jié)果將會允許決定是否執(zhí)行完成,并提供取消執(zhí)行的手段。它的實(shí)現(xiàn)提供了可調(diào)用,靈活的線程池。執(zhí)行類提供了工廠方法最常見的類型和配置,以及一些實(shí)用的方法來使用它們。3.調(diào)查我們進(jìn)行了一項(xiàng)與程序員有關(guān)的調(diào)查，為了收集開發(fā)人員感知的信息，用Java的并發(fā)編程結(jié)構(gòu)的使用。使用這些信息我們可以檢查這些開

21、發(fā)人員的直覺是否反映真實(shí)系統(tǒng)的源代碼。調(diào)查問卷設(shè)計(jì)由Kitchenham和Pfleeger(2008)建議,后階段規(guī)定的作者:規(guī)劃、創(chuàng)建調(diào)查問卷,定義目標(biāo)受眾,評估,進(jìn)行調(diào)查,并分析結(jié)果。首先,我們定義的主題問題。主題:受訪者和并發(fā)編程的經(jīng)驗(yàn),他們是多么熟悉,最后,我們問直接質(zhì)疑使用并發(fā)編程技術(shù)的狀態(tài)。調(diào)查問卷有9個(gè)問題而且由于多項(xiàng)選擇，結(jié)構(gòu)被限制,李克特量表(反應(yīng)了從0到10的規(guī)模,其中0表示沒有知識和10意味著超級專家),也是自由的。它包括一個(gè)問題(# 9)在那兒受訪者可以使用自由文本回答。在問卷中定義所有的問題后,我們得到的是澄清和描述一些問題的解釋的迭代反饋。這種反饋是從一群專家,也從

22、一個(gè)試點(diǎn)調(diào)查中的分析和討論獲得的。結(jié)合問卷調(diào)查的指令,我們包含一些簡單的例子，是為了澄清我們的意圖。表1介紹了調(diào)查問卷的問題。問題的完整列表以及所有調(diào)查的反應(yīng)在網(wǎng)站是可用的。我們的目標(biāo)人群包括執(zhí)行至少一個(gè)承諾一個(gè)分析了工作的開源軟件的程序員。這項(xiàng)工作分析是很重要的項(xiàng)目，在SourceForge上,它使用Subversion作為默認(rèn)版本控制系統(tǒng)。盡管如此,Subversion不一定跟蹤提交作者的電子郵件地址。例如,可以使用一個(gè)匿名提交作者id或一個(gè)假名。事實(shí)上,后者是更常用的電子郵件地址。SourceForge的另一個(gè)問題是,以前的存儲庫對SourceForge來說是外部的,這使得它很難跟蹤他們

23、大量的項(xiàng)目。然后,為了收集這些程序員的電子郵件地址,我們調(diào)查了搬到Github的項(xiàng)目,因?yàn)樗顾菀渍业教峤徽叩碾娮余]件地址。我們發(fā)現(xiàn)搬到Github的72個(gè)項(xiàng)目。在這些項(xiàng)目中,我們發(fā)現(xiàn)2353個(gè)獨(dú)特的電子郵件地址,但是只有1953人有效。調(diào)查這些程序員時(shí),當(dāng)發(fā)送273個(gè)郵件被未知領(lǐng)域通知的服務(wù)器拒絕而且和另一個(gè)18自動回復(fù)消息。在一段20天的時(shí)間里,我們獲得164個(gè)響應(yīng),9.75%的反應(yīng)率。這反應(yīng)率幾乎是高于在調(diào)查發(fā)現(xiàn)在軟件工程領(lǐng)域(Kitchenham Pfleeger,2008)反應(yīng)率的兩倍。表2綜合調(diào)查數(shù)據(jù)。我們可以看到在上面的表中,26%的受訪者有超過12年的軟件開發(fā)經(jīng)驗(yàn),平均而言

24、,受訪者認(rèn)為自己是適度并發(fā)編程經(jīng)驗(yàn)(價(jià)值6范圍從0到10),0表示沒有知識,和10意味著一個(gè)專家)。在他們的經(jīng)驗(yàn)中,前五名最常用的并發(fā)編程構(gòu)造是相同的第一個(gè)版本的Java語言。此外,平均而言,他們認(rèn)為一半的開源項(xiàng)目使用至少有一個(gè)基本的并發(fā)構(gòu)造和30%的項(xiàng)目采用java.util并發(fā)庫。此外,53%的受訪者表示,他們已經(jīng)使用并發(fā)編程技術(shù)來提高性能和/或應(yīng)用程序的可伸縮性。匿名受訪者之一具體描述寫正確的并發(fā)程序和實(shí)現(xiàn)了性能改進(jìn)有多難:并發(fā)性在很多層面上是很艱難的實(shí)際上并行代碼,避免潛在的死鎖等等。如果不是所有的開發(fā)人員在項(xiàng)目上是守紀(jì)律的,也容易在實(shí)踐上打滑，例如正確使用管理鎖等等和創(chuàng)建脆弱的并發(fā)代

25、碼。Java構(gòu)造在細(xì)節(jié)上有所幫助,但是主要的負(fù)擔(dān)仍然落在程序員徹底理解并發(fā)性及其影響上。也有許多缺陷的語言(如在所有環(huán)境中長時(shí)間不能保證一直為原子)java.util并發(fā)實(shí)用程序可以幫助,但只有當(dāng)程序員理解問題并知道方法和工具使用時(shí),才可以避免它。新的JLS版本已經(jīng)平息了一些問題(如:如果我沒記錯(cuò)的話,現(xiàn)在你可以指望所有語句在一個(gè)構(gòu)造函數(shù)返回之前完成,之前不是這樣的),但是語言的特性仍然給開發(fā)人員一個(gè)很大的負(fù)擔(dān)以知道所有的陷阱或開發(fā)全力防守。在本文的其余部分,我們將討論第1節(jié)中提到的基于七個(gè)研究問題的調(diào)查的主要發(fā)現(xiàn)。4.研究設(shè)置本節(jié)介紹我們研究的配置：我們的基本假設(shè)，我們的礦業(yè)基礎(chǔ)設(shè)施和我們采

26、用的度量套件。我們已經(jīng)建立了一套從SourceForge下載的項(xiàng)目的工具，分析源代碼，并且從這些項(xiàng)目中收集度量。 它包括履帶，一個(gè)度量標(biāo)準(zhǔn)收集工具，及一些輔助外殼腳本。我們稱之為基礎(chǔ)設(shè)施。 圖1描繪我們所用的基礎(chǔ)設(shè)施。最初，履帶式填充項(xiàng)目是來自SourceForge的Java項(xiàng)目，包括其各種版本的庫。我們由HTTP請求手段獲得項(xiàng)目，而不直接訪問項(xiàng)目的源代碼庫。 我們用這種做法，因?yàn)槲覀冎魂P(guān)心分析提供給廣大市民的項(xiàng)目發(fā)布，穩(wěn)定版本。資源代碼庫往往不明確標(biāo)識版本而且他們采用方法不一致。而另一方面，SourceForge通過HTTP請求使得它比較容易通過以下方式獲得發(fā)行版本。當(dāng)項(xiàng)目已全部下載，所有的

27、壓縮文件解壓縮到我們的本地存儲庫。我們目前能夠解壓zip，rar，tar，gz，tgz，bz2，tbz，tbz2，bzip2以及7Z文件壓縮。在此之后，度量收集工具解析源代碼，收集指標(biāo)，并將結(jié)果存儲在度量標(biāo)準(zhǔn)庫。最后，它產(chǎn)生的輸入為CSV文件，被R進(jìn)行統(tǒng)計(jì)分析（Ihaka and Gentleman, 1996）。履帶是Crawler4j，4一個(gè)開源Web的擴(kuò)展履帶式框架。這個(gè)框架是多線程的，并寫在Java中。我們還實(shí)施了其他腳本來組織項(xiàng)目,根據(jù)現(xiàn)有的日期在SourceForge和版本檢查目標(biāo)項(xiàng)目準(zhǔn)備進(jìn)行分析，必要時(shí)確定其結(jié)構(gòu)時(shí)。為了收集并發(fā)性的指標(biāo)，我們使用了JavaCompiler的類來分

28、析源代碼和生成分析樹。樹木遍歷和度量被提取并存儲在文本文件。該延長的指標(biāo)包括計(jì)數(shù)類控制線Thread類，實(shí)現(xiàn)Runnable接口的類，并且一些Java關(guān)鍵字的用途，如同步，易失性，以及類型實(shí)例化屬于JUC的數(shù)庫，如AtomicInteger，ConcurrentHashMap，ReentrantLock和很多其他的。表3列出了我們已經(jīng)測量的元素的出現(xiàn)次數(shù)。我們的分析完全專注于成熟穩(wěn)定的項(xiàng)目，然后確定項(xiàng)目開發(fā)。此外，在2004之后沒有至少一個(gè)釋放的項(xiàng)目是不考慮的，因?yàn)閖ava.util.concurrent被釋放作為于2004年十二月發(fā)布的JDK的一部分，而且為了避免瑣碎的系統(tǒng)，我們只檢查有著至

29、少1000控制線的項(xiàng)目。我們已經(jīng)分析同時(shí)考慮他們的最新版本及其沿時(shí)間演變的項(xiàng)目。在后一種情況下，我們已經(jīng)研究了多個(gè)版本的項(xiàng)目。為了更好地了解他們的發(fā)展，我們也計(jì)算在一些考慮到最近和以前的系統(tǒng)的版本的指標(biāo)值的差異。然后，我們計(jì)算的Pearson相關(guān)（Pearson，1936年），在這些差異之間。這幫助我們確定，例如，若干項(xiàng)目呈現(xiàn)一個(gè)傾向，從直接繼承Thread類來使用執(zhí)行切換到管理線程執(zhí)行。本文中給出的所有結(jié)果被歸一化，以避免造成非常大的絕對值的扭曲和使它們更直接比較。例如，在2011.08.22計(jì)算結(jié)果是在Dr.Java項(xiàng)目的版本中，度量實(shí)現(xiàn)Runnable釋放，我們分好幾次實(shí)現(xiàn)Runnabl

30、e，這是6，通過代碼行的數(shù)目，這是112703，導(dǎo)致0.000053238。這個(gè)結(jié)果之后是100000倍而且最后的結(jié)果是5.3238。所有收集的指標(biāo)以這種方式正?；?，我們在本文的其余部分使用這些標(biāo)準(zhǔn)值。關(guān)于整個(gè)文章的絕對值的引用被明確提出。兩者的絕對和為所有度量的歸一化值以提供本文的配套網(wǎng)站。最后，根據(jù)調(diào)查結(jié)果，我們提出了一些假設(shè)，代表關(guān)于開發(fā)者的期望，盡管國家使用了一些并發(fā)編程技術(shù)。我們假設(shè)有以下幾種：A1 Java項(xiàng)目經(jīng)常使用并行編程結(jié)構(gòu)（平均估計(jì)值：51.43）;A2 Java項(xiàng)目經(jīng)常使用j.u.c庫來構(gòu)建（平均估計(jì)值：36.63）;A3同步方法是最常用的并行編程結(jié)構(gòu);A4 Concur

31、rentHashMap的是j.u.c.編程結(jié)構(gòu)中使用最頻繁的并發(fā);A5舉措重新設(shè)計(jì)現(xiàn)有的系統(tǒng)，因?yàn)楦軛U多核架構(gòu)是家常便飯。2.外文原文A large-scale study on the usage of Javas concurrent programming constructs1. IntroductionMulticore systems offer the potential for cheap, scalable, high-performance computing and also for significant reductions in power consumption.

32、 To achieve this potential, it is essential to take advantage of new heterogeneous architectures comprising collections of multiple processing elements. To leverage multicore technology, applications must be concurrent, which poses a challenge, since it is well-known that concurrent programming is h

33、ard( HYPERLINK /science/article/pii/S0164121215000849 l bib0039 Sutter, 2005). A number of programming languages provide constructs for concurrent programming. These solutions vary greatly in terms of abstraction, error-proneness, and performance. The Java programming language is particularly rich w

34、hen it comes to concurrent programming constructs. For example, it includes the concept of monitor, a low-level mechanism supporting both mutual exclusion and condition-based synchronization, as well as a high-level library( HYPERLINK /science/article/pii/S0164121215000849 l bib0018 Lea, 2005),java.

35、util.concurrent, also known asj.u.c., introduced in version 1.5 of the language.In both academia and industry, there is a strong belief that multicore technology will radically change the way software is built. However, to the best of our knowledge, there is a lack of reliable information about the

36、current state of the practice of the development of concurrent software in terms of the constructs that developers employ. In this work, we aim to partially fill this gap.Specifically, we present an empirical study aimed at establishing the current state of the practical usage of concurrent programm

37、ing constructs in Java applications. We have analyzed 2227 stable and mature Java projects comprising more than 600 million lines of code (LoCwithout blank lines and comments) from SourceForge, one of the most popular open source code repositories. Our analysis encompasses several versions of these

38、applications and is based on more than 50 source code metrics that we have automatically collected. We have also studied correlations among some of these metrics in an attempt to find trends in the use of concurrent programming constructs. We have chosen Java because it is a widely used object-orien

39、ted programming language. Moreover, as we said before, it includes support for multithreading with both low-level and high-level mechanisms. Additionally, it is the language with the highest number of projects in SourceForge.Evidence on how concurrent programs are written can raise developer awarene

40、ss about available mechanisms. It can also indicate how well-accepted some of these mechanisms are in practice. Moreover, it can inform researchers designing new mechanisms about the kinds of constructs that developers may be more willing to use. Tool vendors can also benefit by supporting developer

41、s in the use of lesser-known, more efficient mechanisms, for example, by implementing novel refactorings( HYPERLINK /science/article/pii/S0164121215000849 l bib0006 Dig, Marrero, Ernst, 2009, HYPERLINK /science/article/pii/S0164121215000849 l bib0016 Ishizaki, Daijavad, Nakatani, 2011and HYPERLINK /

42、science/article/pii/S0164121215000849 l bib0036 Schfer, Sridharan, Dolby, Tip, 2011a). Furthermore, results such as those uncovered by this study can support lecturers in more convincingly arguing students into the importance of concurrent programming, not only for the future of software development

43、, but also for the present.Mining data from the SourceForge repository poses several challenges. Some of them are inherent to the process of obtaining reliable data. These derive mainly from two factors: scale and lack of a standard organization for source code repositories. Others pertain to transf

44、orming the data into useful information. HYPERLINK /science/article/pii/S0164121215000849 l bib0012 Grechanik etal. (2010)discussed a few challenges that make it difficult to obtain evidence from source code. For example, getting the source code of all software versions is difficult because there is

45、 no naming pattern to define if a compressed file contains source code, binary code or something else. Furthermore, it is difficult to be sure that an error has not occurred during measurement, due to the number of projects and project versions. We address these challenges by creating an infrastruct

46、ure for obtaining and processing large code bases, specifically targeting SourceForge. In addition, we have conducted a survey with the committers of some of these projects as an attempt to verify whether their beliefs are supported by our data.Based on the data we have obtained, we propose to answe

47、r a number of research questions (RQ).1.1. RQ1: Do Java applications use concurrent programming constructs?We found out that more than 75% of the most recent versions of the examined projects include some form of concurrent programming, e.g., at least one occurrence of the synchronizedkeyword. In me

48、dium projects (20,001100,000 LoC) this percentage grows to more than 90% and reaches 100% for large projects (over 100,000 LoC). In addition, the mean numbers (per 100,000 LoC) ofsynchronizedmethods, classes extendingThread, and classes implementingRunnableare, respectively, 66.75, 13, and 13.85. Th

49、ese results indicate that projects often use concurrent programming constructs and a considerable number do so intensively. HYPERLINK /science/article/pii/S0164121215000849 l fn0001 1On the other hand, perhaps counterintuitively, the overall percentage of concurrent projects has not seen significant

50、 change throughout the years, despite the pervasiveness of multicore machines.1.2. RQ2: Have developers moved to library-based concurrency?Our data shows that only 23.21% of the analyzed concurrent projects employ classes of the java.util.concurrentlibrary. On the other hand, there has been a growth

51、 in the adoption of this library. However, this growth does not in general seem to be related to a decrease in the use of Javas traditional concurrent programming constructs, with a few exceptions. Furthermore, projects that have been in active development more recently, i.e., had at least one versi

52、on released since 2009, employ thejava.util.concurrentlibrary more intensively than the mean. Therefore, the percentage of active, mature projects that use that library is actually higher than 23.21%.1.3. RQ3: How do developers protect shared variables from concurrent threads?Most of the projects us

53、esynchronizedblocks and methods. Thevolatilemodifier, explicit locks (including variations such as read-write locks), and atomic variables are less common, albeit some of them seem to be growing in popularity. We also noticed a tendency of growth in the use ofsynchronizedblocks. In particular, the g

54、rowth in their use correlates positively with the growth in the use of atomic data types, explicit locks, and thevolatilemodifier.1.4. RQ4: Do developers still use thejava.lang.Threadclass to create and manage threads?We found out that implementing theRunnableinterface is the most common approach to

55、 define new threads. Moreover, a considerable number of projects employExecutors to manage thread execution (11.14% of the concurrent projects). It was possible to observe that projects that employ executors exhibit a weak tendency to reduce the number of classes that explicitly extend the Thread cl

56、ass.1.5. RQ5: Are developers using thread-safe data structures?We observed that developers are still using mostlyHashtableandHashMap, even though the former is thread-safe but inefficient and the latter is not thread-safe. Notwithstanding, there is a tendency towards the use ofConcurrentHashMapas a

57、replacement for other associative data structures in a number of projects.1.6. RQ6: How often do developers employ condition-based synchronization?A large number of concurrent projects include invocations of thenotify(),notifyAll(), orwait()methods. At the same time, we noticed that a small number o

58、f projects have eliminated many uses of these methods, employing theCountDownLatchclass, part of thejava.util.concurrentlibrary, instead. This number is not large enough for statistical analysis. Nevertheless, it indicates that mechanisms with simple semantics likeCountDownLatchhave potential to, in

59、 some contexts, replace lower-level, more traditional ones.1.7. RQ7: Do developers attempt to capture exceptions that might cause abrupt thread failure?Our data indicates that less than 3% of the concurrent projects implement theThread.UncaughtExceptionHandlerinterface, which means that, in 97% of t

60、he concurrent projects, an exception stemming from a programming error might cause threads to die silently, potentially affecting the behavior of threads that interact with them. Moreover, analyzing these implementations, we discovered that developers often do not know what to do with uncaught excep