鄭 冰,李 華

(內(nèi)蒙古大學(xué) 計(jì)算機(jī)學(xué)院,呼和浩特 010021)

1 引 言

SDN架構(gòu)的網(wǎng)絡(luò)中,控制器是負(fù)責(zé)管理底層網(wǎng)絡(luò)的核心和關(guān)鍵組成部分[1,2],也是承載功能豐富的管理軟件的網(wǎng)絡(luò)操作系統(tǒng),其質(zhì)量對(duì)自己所承載的應(yīng)用有很大影響.現(xiàn)有研究結(jié)果[2]表明,包括原型級(jí)控制器在內(nèi),65%以上的控制器均采用了多線程的并發(fā)編程技術(shù),蘊(yùn)含著并發(fā)缺陷,帶來了網(wǎng)絡(luò)運(yùn)行的不確定.由于SDN的邏輯分層,天然具有異步性,使得并發(fā)缺陷更加需要關(guān)注.發(fā)現(xiàn)與修復(fù)并發(fā)缺陷是重要但耗時(shí)的工作.因此,極有必要對(duì)SDN控制器的并發(fā)缺陷及修復(fù)過程進(jìn)行深入細(xì)化的研究.如果能夠進(jìn)行量化分析,對(duì)于它的缺陷修復(fù)具有更強(qiáng)的指導(dǎo)意義.

為了便于研究,研究對(duì)象限于代碼和缺陷倉庫開放訪問的開源SDN控制器.現(xiàn)有開源SDN控制器主要分為兩種[3]:作為某公司開發(fā)的產(chǎn)品的一部分在生產(chǎn)環(huán)境中應(yīng)用和在學(xué)術(shù)研究中作為基礎(chǔ)平臺(tái)使用.雖然SDN控制器的實(shí)現(xiàn)技術(shù)各有不同,但均是基于SDN思想,實(shí)現(xiàn)大致相同的核心功能,提供類似的服務(wù)功能集合,因此各SDN控制器可能會(huì)出現(xiàn)相似的缺陷[3].通過針對(duì)現(xiàn)有研究和工業(yè)界應(yīng)用情況的調(diào)研,開源SDN控制器按照應(yīng)用場景分為3類:商業(yè)級(jí)通用、原型級(jí)通用和特定場景應(yīng)用.基于調(diào)研結(jié)果總結(jié)了每類別中具有代表性的控制器及其代碼級(jí)特征,如表1所示.

表1 按應(yīng)用場景分類的開源SDN控制器(1)http://www.openhub.net,2021-04(部分)Table 1 Open source SDN controllers by application scenario1(part)

在SDN控制器并發(fā)控制實(shí)現(xiàn)過程中,采用了相應(yīng)的并發(fā)編程技術(shù),表1中列出的控制器均是如此.相比單線程控制器,多線程控制器適用于更復(fù)雜的環(huán)境,例如5G、SD-WAN和物聯(lián)網(wǎng)等商業(yè)用途[4].發(fā)現(xiàn)與修復(fù)并發(fā)缺陷需要研究分析并發(fā)缺陷表征和修復(fù)過程相關(guān)的特征[5],通過對(duì)該特征的分析,有利于并發(fā)缺陷的再現(xiàn)和修復(fù)策略的制定.在軟件缺陷管理工具的歷史缺陷倉庫和軟件代碼倉庫的提交記錄中保存了多個(gè)維度的缺陷表征和修復(fù)過程信息,因此可以基于該類數(shù)據(jù)進(jìn)行特征量化分析.

下面以缺陷管理工具Jira獲取的1個(gè)SDN控制器OpenDaylight(以下簡稱ODL)項(xiàng)目的真實(shí)歷史缺陷作為實(shí)例簡述研究動(dòng)機(jī).編號(hào)OPNFLWPLUG-1090(2)https://jira.opendaylight.org/browse/OPNFLWPLUG-1090,2021-04的缺陷報(bào)告所描述的缺陷發(fā)生在ODL南向接口插件SDN原生協(xié)議子項(xiàng)目OpenFlowPlugin中,具體表征及修復(fù)過程:1)報(bào)告者提交報(bào)告:單節(jié)點(diǎn)ODL控制器16臺(tái)交換機(jī)部署下,在初始連接階段出現(xiàn)了部分交換機(jī)連接請求被拒絕的情況;2)報(bào)告者和開發(fā)者通過評(píng)論區(qū)的討論認(rèn)為原因是由于多臺(tái)交換機(jī)同一時(shí)間的握手請求引發(fā)了數(shù)據(jù)競爭,并且這一問題極有可能在大規(guī)模部署的生產(chǎn)環(huán)境中發(fā)生;3)開發(fā)者在代碼倉庫提交修復(fù)補(bǔ)丁代碼;4)開發(fā)者在Jira中給出2個(gè)ODL版本的修復(fù)代碼鏈接,并修改該缺陷報(bào)告的狀態(tài)為“已解決”.

通過以上實(shí)例可以看到,真實(shí)的歷史缺陷報(bào)告可以提供并發(fā)缺陷表征和修復(fù)過程的有用信息.本文以缺陷倉庫真實(shí)歷史并發(fā)缺陷數(shù)據(jù)為研究對(duì)象,采用量化分析的方式給出SDN控制器平臺(tái)并發(fā)缺陷在典型并發(fā)缺陷類型的分布特征和修復(fù)過程的特征.不同SDN控制器項(xiàng)目并發(fā)缺陷的特征存在可能的共性,這些特征能夠作為模式和規(guī)律傳遞的橋梁,有助于在SDN控制器平臺(tái)上的應(yīng)用程序的開發(fā)和調(diào)試,對(duì)SDN相關(guān)產(chǎn)品的理解、發(fā)展和管理也有幫助.本文所指的缺陷量化分析是將SDN控制器軟件缺陷倉庫保存的歷史缺陷在產(chǎn)生和修復(fù)過程中產(chǎn)生的相關(guān)信息提取為多個(gè)維度的度量數(shù)據(jù),統(tǒng)計(jì)量化計(jì)算分析度量數(shù)據(jù)的活動(dòng).并發(fā)缺陷特征是指在典型并發(fā)缺陷類型的數(shù)量分布特征和修復(fù)過程特征.

本文工作貢獻(xiàn)如下:

1)給出一種半自動(dòng)化量化分析SDN控制器并發(fā)性缺陷的框架方法;從軟件缺陷管理周期出發(fā),提出與SDN控制器軟件并發(fā)缺陷數(shù)量修復(fù)過程相關(guān)的時(shí)間因素、缺陷影響、重要性和復(fù)雜度以及修復(fù)影響4個(gè)維度及10個(gè)具體度量,并給出度量指標(biāo)的提取和計(jì)算方法;

2)在兩個(gè)廣泛使用的SDN控制器ODL和ONOS上進(jìn)行了一系列實(shí)證研究.基于所給出的修復(fù)過程度量,對(duì)所獲取的SDN控制器并發(fā)缺陷進(jìn)行量化分析,給出了在典型并發(fā)缺陷類型的數(shù)量分布和修復(fù)過程特征的對(duì)比量化分析結(jié)果;給出了經(jīng)過處理后的數(shù)據(jù)集,包含本文從ODL和ONOS所提取的修復(fù)過程特征的并發(fā)缺陷數(shù)據(jù).

本文的其余部分組織如下:第2部分是相關(guān)工作,介紹與SDN控制器并發(fā)缺陷分析的相關(guān)工作并提出本文的研究問題;第3部分提出一種量化分析框架,給出修復(fù)過程度量,詳細(xì)闡述了所采用的研究方法;第4部分給出SDN 控制器軟件并發(fā)缺陷的量化分析結(jié)果,并進(jìn)行了有效性分析;第5部分總結(jié)全文并給出未來工作展望.

2 相關(guān)工作

目前針對(duì)SDN控制器缺陷的研究工作主要從以下幾個(gè)方面展開:通過文獻(xiàn)綜述的方法進(jìn)行缺陷特征的分析,Yu等人[6]給出了SDN中可能出現(xiàn)缺陷的表征及根因;通過來自學(xué)術(shù)研究和生產(chǎn)運(yùn)維中的觀察及經(jīng)驗(yàn)總結(jié)缺陷特征,Canini等人[7]關(guān)注了SDN控制器應(yīng)用程序中存在的邏輯缺陷;通過實(shí)證研究的方法,利用真實(shí)缺陷報(bào)告獲得SDN控制器缺陷特征,Vizarreta等人[5]通過統(tǒng)計(jì)分析方法給出了所報(bào)告缺陷數(shù)量的學(xué)習(xí)曲線模式和錯(cuò)誤檢測率的變化規(guī)律,又通過對(duì)ODL和ONOS控制器缺陷的研究[3],專門關(guān)注由分布式SDN控制器集群造成的缺陷,給出了缺陷的分類和根因分析.這些研究引入了預(yù)測SDN控制器缺陷數(shù)量、位置的模型和工具,但是并沒有考慮特定的并發(fā)缺陷類型及其修復(fù)過程特征.關(guān)于SDN控制器的并發(fā)缺陷,Miserez等人[8]研究了SDN控制器和交換機(jī)交互引入的并發(fā)缺陷,并基于事件執(zhí)行的有向無環(huán)圖給出了相應(yīng)的并發(fā)缺陷檢測工具SDNRacer;MAY等人[9]進(jìn)一步給出了SDN并發(fā)缺陷的檢測工具BigBug.這些研究更多關(guān)注的是SDN架構(gòu)中南向交互引入的并發(fā)缺陷及其檢測,并沒有過多關(guān)注由于控制器軟件本身的多線程和分布式部署引發(fā)的并發(fā)缺陷及其修復(fù)過程特征.

由于不確定性,并發(fā)缺陷在開發(fā)和維護(hù)過程中的檢測與修復(fù)一直是困擾開發(fā)者和使用者的難題.對(duì)于其他軟件系統(tǒng)并發(fā)缺陷的研究有:Leesatapornwongsa 等人[10]對(duì)于數(shù)據(jù)中心分布式系統(tǒng)并發(fā)缺陷的表征、觸發(fā)原因等進(jìn)行了研究;Lu等人[11]對(duì)現(xiàn)實(shí)世界的真實(shí)并發(fā)缺陷進(jìn)行了廣泛研究;Gunawi等人[12]在對(duì)3000多個(gè)真實(shí)云系統(tǒng)故障事件的研究中,關(guān)注了由并發(fā)缺陷帶來的云系統(tǒng)不確定性;石劍君等人[13]對(duì)操作系統(tǒng)并發(fā)缺陷的研究現(xiàn)狀進(jìn)行了分析.但是不同領(lǐng)域軟件系統(tǒng)的并發(fā)缺陷都會(huì)有所不同[10],對(duì)于SDN控制器這類網(wǎng)絡(luò)操作系統(tǒng)亦是如此[8],需要進(jìn)行有針對(duì)性研究.

從真實(shí)缺陷報(bào)告中提取數(shù)據(jù)進(jìn)行缺陷特征的分析,在許多與缺陷相關(guān)的研究中扮演著重要的基礎(chǔ)性角色,相關(guān)研究包括:Zaman等人[14]對(duì)Firefox和Chrome的性能和非性能缺陷報(bào)告進(jìn)行了量化分析,發(fā)現(xiàn)性能故障比非性能故障更難處理;Catolino等人[15]通過量化分析的方法研究了軟件缺陷的根因分類和特征;Zheng等人[16]專門針對(duì)云平臺(tái)OpenStack缺陷報(bào)告中的歷史缺陷進(jìn)行挖掘,給出了觸發(fā)云平臺(tái)缺陷的事件因素和動(dòng)作特征.對(duì)缺陷報(bào)告的挖掘分析可以通過對(duì)所關(guān)注的特定度量指標(biāo)的量化統(tǒng)計(jì)分析實(shí)現(xiàn)[17].

缺陷是軟件產(chǎn)品期望屬性的偏離,現(xiàn)有研究并沒有對(duì)于真實(shí)SDN控制器并發(fā)缺陷的數(shù)量分布及其具體修復(fù)過程特征的研究.因此本文提出以下研究問題:

RQ1:SDN 控制器在各類型并發(fā)缺陷上的數(shù)據(jù)分布特征如何?各類型并發(fā)缺陷在SDN控制器各功能模塊上的數(shù)據(jù)分布特征如何?

RQ2:以缺陷修復(fù)過程的多維度量作為表征,SDN控制器并發(fā)缺陷的修復(fù)過程特征是什么? SDN控制器的并發(fā)與非并發(fā)缺陷在修復(fù)過程特征上的區(qū)別是什么?

3 研究方法

3.1 方法的整體框架

SDN控制器并發(fā)缺陷的量化分析需要領(lǐng)域知識(shí)和對(duì)代碼庫的熟悉才能獲得有意義的變化規(guī)律和分布特征[18].為了解決前面提出的問題,給出量化分析方法的框架如圖1所示,具體步驟如下:

圖1 SDN控制器并發(fā)缺陷量化分析方法框架Fig.1 Framework of quantitative analysis method for concurrent bugs of SDN controller

步驟1.數(shù)據(jù)收集及預(yù)處理.自動(dòng)化進(jìn)行缺陷報(bào)告數(shù)據(jù)的采集構(gòu)成原始數(shù)據(jù)集BD;對(duì)文本數(shù)據(jù)進(jìn)行預(yù)處理,生成文本語料數(shù)據(jù)集.

步驟2.修復(fù)過程特征提取.依據(jù)軟件缺陷生命周期,提出修復(fù)過程的分析維度,給出修復(fù)過程度量和計(jì)算方法,利用Python工具計(jì)算提取修復(fù)過程特征,構(gòu)成具有修復(fù)過程特征的數(shù)據(jù)集BD*.

步驟3.生成并發(fā)缺陷研究數(shù)據(jù)集.給出并發(fā)缺陷類型作為分類依據(jù),利用自己設(shè)計(jì)的Python工具實(shí)現(xiàn)基于關(guān)鍵字檢索缺陷報(bào)告文本語料集,獲得候選缺陷報(bào)告.通過對(duì)代碼提交記錄和候選缺陷報(bào)告的人工篩選進(jìn)行交叉驗(yàn)證,結(jié)合BD*獲得具有修復(fù)過程特征的并發(fā)缺陷報(bào)告數(shù)據(jù)集CD.通過對(duì)BD*中的非并發(fā)缺陷報(bào)告進(jìn)行分層隨機(jī)采樣獲得比較分析需要的非并發(fā)缺陷數(shù)據(jù)集樣本NCD.

步驟4.并發(fā)缺陷量化分析.給出量化統(tǒng)計(jì)分析方法,基于數(shù)據(jù)集CD和NCD,給出具體的量化分析結(jié)果,回答研究問題.

3.2 數(shù)據(jù)收集及預(yù)處理

開源社區(qū)缺陷管理工具(例如,Jira、Bugzilla)的缺陷倉庫保存的歷史缺陷報(bào)告數(shù)據(jù)可以公開訪問直接獲取.現(xiàn)有研究主要通過缺陷管理工具提供的開放API(Application Programming Interface)下載和爬蟲爬取兩種方式自動(dòng)獲取缺陷報(bào)告數(shù)據(jù)[16].為了確保數(shù)據(jù)集中只包含真正的歷史缺陷,選擇“Issue type”為“Bug”的缺陷報(bào)告,并保留缺陷管理工具中提供的所有預(yù)定義標(biāo)簽的數(shù)據(jù)作為量化分析的數(shù)據(jù)來源.雖然缺陷管理工具可能不同,項(xiàng)目定義的標(biāo)簽也會(huì)有所區(qū)別,但是按照通用的缺陷管理流程,一般由以下預(yù)定義標(biāo)簽組成:編號(hào)(Issue ID)類型(Issue type)、狀態(tài)(Status)、創(chuàng)建者(Created)、優(yōu)先級(jí)(Priority)、建立日期(Created)、摘要(Summary)、描述(Description)和評(píng)論(Comments)等.這些信息構(gòu)成了以缺陷報(bào)告編號(hào)為索引的包含m條缺陷報(bào)告原始數(shù)據(jù)集合BD={b1,b2,…,bj,…,bm},其中,預(yù)定義標(biāo)簽是缺陷報(bào)告bj的默認(rèn)屬性,具有量化分析所需要的元數(shù)據(jù)信息,可以直接映射或派生為并發(fā)缺陷修復(fù)過程的具體度量.

對(duì)于缺陷報(bào)告bj中的文本數(shù)據(jù),是由缺陷報(bào)告者和開發(fā)者提供的自然語言描述文本[5].具體包括:

1)摘要:是對(duì)缺陷問題核心的簡練概括描述;

2)詳細(xì)描述:不僅有自然語言描述,也時(shí)常附有觸發(fā)缺陷的執(zhí)行路徑、代碼片段、輸出日志等,還可能包括報(bào)告者對(duì)于修復(fù)措施的建議;

3)評(píng)論:包含了開發(fā)者和報(bào)告者之間關(guān)于如何診斷和解決缺陷問題以及對(duì)于具體修復(fù)措施的討論,也包含在代碼倉庫的修復(fù)鏈接.

缺陷文本中的信息可以作為識(shí)別并發(fā)缺陷以及修復(fù)過程度量提取(例如并發(fā)缺陷所影響的節(jié)點(diǎn)數(shù)目)的數(shù)據(jù)來源.將3個(gè)字段的文本內(nèi)容以缺陷報(bào)告編號(hào)為索引進(jìn)行拼接,構(gòu)成分析所需要的文本語料集.然后,在原始數(shù)據(jù)集BD的基礎(chǔ)上,計(jì)算提取修復(fù)過程度量,基于文本語料數(shù)據(jù)集和相應(yīng)代碼倉庫的提交記錄篩選并發(fā)缺陷.

3.3 修復(fù)過程特征提取

在缺陷管理工具中,缺陷生命周期是缺陷在最終解決之前所要經(jīng)歷的多個(gè)階段,其核心任務(wù)是修復(fù)軟件缺陷,因此本文所研究的特征關(guān)注了缺陷修復(fù)過程特征.在缺陷生命周期管理過程中,基于缺陷管理工具的典型缺陷修復(fù)過程如下[5,19]:1)報(bào)告者提交一個(gè)缺陷報(bào)告;2)缺陷被分配給開發(fā)者;3)開發(fā)者診斷缺陷并確定修復(fù)策略,這期間可以通過評(píng)論區(qū)與報(bào)告者進(jìn)行交互;4)開發(fā)者修復(fù)缺陷,并標(biāo)記缺陷報(bào)告狀態(tài)為“已解決”或“修復(fù)”.

結(jié)合典型缺陷修復(fù)過程,基于BD數(shù)據(jù)集中包含的元數(shù)據(jù)信息,以下給出缺陷修復(fù)過程中所關(guān)注的4個(gè)維度和10個(gè)修復(fù)過程度量的定義和相應(yīng)的形式化描述.

定義 1.(缺陷修復(fù)過程(FTP)).假設(shè)所有缺陷報(bào)告都被分配了正確的狀態(tài)和優(yōu)先級(jí),缺陷修復(fù)過程表示為四元組FTP={T,S,I,F},其中:

·T表示缺陷修過程中的時(shí)間因素,可以表示為三元組T= {t_tr,t_dr,t_acomm},缺陷修復(fù)過程中涉及的主要時(shí)間點(diǎn)包括,從缺陷的報(bào)告開始,期間的評(píng)論互動(dòng),再到最后的缺陷解決或修復(fù),可以反映缺陷修復(fù)的效率;

·S表示缺陷影響的范圍,可以表示為二元組S={n_affv,n_node},由報(bào)告者或開發(fā)者認(rèn)定缺陷發(fā)生所影響的版本數(shù)和節(jié)點(diǎn)數(shù),可以反映缺陷發(fā)生的具體部署配置,對(duì)修復(fù)過程也會(huì)產(chǎn)生影響;

·I表示重要性和復(fù)雜度,由三元組I={priority,n_comm,n_sdc}表示,是開發(fā)者或報(bào)告者認(rèn)為缺陷對(duì)于軟件質(zhì)量影響的重要程度以及表征修復(fù)缺陷本身的復(fù)雜程度;

·F表示修復(fù)結(jié)果,可以表示為二元組F={n_patches,n_fixv},是開發(fā)者對(duì)缺陷修復(fù)的最終結(jié)果.

針對(duì)4個(gè)維度中的指標(biāo),依據(jù)可獲取原則,本文選取了10個(gè)具體度量,其詳細(xì)描述如表2所示.

表2 并發(fā)缺陷修復(fù)過程量化分析維度及具體度量Table 2 Quantitative analysis of the measurement and metrics of concurrent bugs fix process

利用Python工具自動(dòng)化實(shí)現(xiàn)具體度量數(shù)據(jù)的計(jì)算提取,所采用的方式包括從數(shù)據(jù)集中直接獲取、通過計(jì)算派生和通過文本提取3類:

1)在直接獲取的數(shù)據(jù)中,補(bǔ)丁數(shù)n_patches是通過代碼倉庫的提交記錄和代碼審計(jì)倉庫獲得.

2)通過計(jì)算派生的數(shù)據(jù)主要指時(shí)間因素(T)中的度量,其中,平均評(píng)論時(shí)間間隔t_acomm可以表征每條缺陷報(bào)告的報(bào)告者和開發(fā)者之間互動(dòng)的頻率,所設(shè)計(jì)的計(jì)算方法如公式(1)所示:

(1)

其中k表示缺陷報(bào)告的評(píng)論數(shù)(n_comm=k),t_commi表示該缺陷報(bào)告第i條評(píng)論的提交時(shí)間.

3)通過文本提取的數(shù)據(jù)主要指節(jié)點(diǎn)數(shù)n_node,可以表征發(fā)生缺陷時(shí)的具體部署配置,這里的節(jié)點(diǎn)數(shù)主要指發(fā)生缺陷時(shí)的SDN控制器的節(jié)點(diǎn)數(shù)目.具體賦值方法:節(jié)點(diǎn)數(shù)對(duì)缺陷無影響或缺陷報(bào)告中描述模糊的情況,均賦值為0;單控制器節(jié)點(diǎn)部署賦值為1;控制器集群部署情形下按照具體節(jié)點(diǎn)數(shù)賦值.

為了保證所分析的并發(fā)缺陷的準(zhǔn)確性,只關(guān)注已解決和已修復(fù)的歷史缺陷報(bào)告.從原始數(shù)據(jù)集BD的m條缺陷報(bào)告中篩選出n條符合要求的報(bào)告,按照上述方法,計(jì)算提取出FTP 4個(gè)維度的度量,形成數(shù)據(jù)集BD*.

3.4 生成并發(fā)缺陷研究數(shù)據(jù)集

為了有效的收集SDN控制器的歷史并發(fā)缺陷,采用基于關(guān)鍵字的檢索方式篩選并發(fā)缺陷[17,18,20].在文本語料具備相關(guān)信息的基礎(chǔ)上,需要進(jìn)行并發(fā)缺陷相關(guān)的關(guān)鍵字的選擇.本文關(guān)注的并發(fā)缺陷是指:兩個(gè)或兩個(gè)以上的線程因交互作用于一個(gè)或多個(gè)共享資源而引起的程序崩潰或掛起,或產(chǎn)生與串行執(zhí)行不同的結(jié)果,且這樣的結(jié)果是不確定的.表3給出了具體并發(fā)缺陷類型的描述及對(duì)應(yīng)的檢索關(guān)鍵字.

生成并發(fā)缺陷研究數(shù)據(jù)集的過程如下:

1)對(duì)文本語料集進(jìn)行篩選,保留已完成和已修復(fù)缺陷報(bào)告的n條語料數(shù)據(jù),包含了各種類型的缺陷,基于表3中的關(guān)鍵字,利用Python工具采用檢索技術(shù)篩出包含一個(gè)或多個(gè)關(guān)鍵字及其單詞變形的缺陷報(bào)告,獲得候選集.

表3 并發(fā)缺陷類型描述與關(guān)鍵字Table 3 Description and keywords of concurrent bugs

2)通過對(duì)候選集與代碼倉庫中的提交記錄進(jìn)行交叉核對(duì)的人工篩選方法獲得SDN控制器的真實(shí)并發(fā)缺陷,并在數(shù)據(jù)集中標(biāo)記具體并發(fā)缺陷類型,生成并發(fā)缺陷報(bào)告數(shù)據(jù)集CD.其中代碼提交記錄可以從缺陷報(bào)告中的修復(fù)鏈接獲取,也可以從代碼倉庫(例如Git)的提交日志獲取.

3)為了進(jìn)行對(duì)比分析,采用分層抽樣的方式篩選同等數(shù)量非并發(fā)缺陷樣本.將所有非并發(fā)缺陷數(shù)據(jù)按照缺陷報(bào)告創(chuàng)建日期和所屬的功能模塊劃分為多個(gè)類別,以保證所選取的樣本盡量與并發(fā)缺陷報(bào)告具有相同的分布,減少后續(xù)量化分析中的誤差,然后從每個(gè)類別中隨機(jī)抽樣選擇缺陷報(bào)告組成非并發(fā)缺陷對(duì)比分析數(shù)據(jù)集NCD.

3.5 量化分析方法

采用的具體統(tǒng)計(jì)分析方法包括:

1)對(duì)于分類數(shù)據(jù),通過統(tǒng)計(jì)不同分類下的數(shù)量,給出頻數(shù)和頻率(頻數(shù)與數(shù)據(jù)總數(shù)的比值)分布.

2)對(duì)于數(shù)據(jù)分布特征的描述性統(tǒng)計(jì),通過統(tǒng)計(jì)學(xué)中常用的集中趨勢分析給出,采用的測度值包括,平均值、中位數(shù)、四分位數(shù)(75%)、極大值和眾數(shù).

3)兩個(gè)獨(dú)立樣本比較檢驗(yàn),對(duì)于需要進(jìn)行兩組數(shù)據(jù)的對(duì)比分析時(shí),統(tǒng)計(jì)學(xué)中經(jīng)常假設(shè)數(shù)據(jù)滿足某種分布,由于待檢驗(yàn)數(shù)據(jù)集中的數(shù)據(jù)特征不一定遵循特定的分布,因此,并不假設(shè)數(shù)據(jù)服從某種分布,為了檢驗(yàn)兩個(gè)獨(dú)立樣本數(shù)據(jù)組間(并發(fā)缺陷和非并發(fā)缺陷)的特征值(修復(fù)過程特征)是否存在顯著差異,使用Mann-Whitney U檢驗(yàn)方法[16](簡稱MW U檢驗(yàn))進(jìn)行統(tǒng)計(jì)檢驗(yàn),這是一種非參數(shù)檢驗(yàn),并且不需要做出數(shù)據(jù)具有正態(tài)分布的假設(shè).顯著性水平α=0.05取,如果p<0.05時(shí)認(rèn)為所檢驗(yàn)的兩組數(shù)據(jù)間存在統(tǒng)計(jì)學(xué)上的顯著差異.其中,p 值(P-value)是當(dāng)原假設(shè)為真時(shí),所得到的樣本觀察結(jié)果或更極端結(jié)果出現(xiàn)的概率,p值也稱為觀察到的顯著性水平.

通過上述方法量化分析比較不同控制器之間以及控制器的并發(fā)缺陷和非并發(fā)缺陷在不同度量上的分布特征.

4 實(shí)例分析

4.1 實(shí)例研究對(duì)象選取

在采用實(shí)例進(jìn)行研究時(shí),選擇有代表性的SDN控制器作為實(shí)例研究對(duì)象非常重要.為了確保代表性所采用的選擇標(biāo)準(zhǔn)是:缺陷倉庫可以公開訪問且有至少1000條的缺陷報(bào)告;代碼倉庫可以公開訪問,社區(qū)達(dá)到一定規(guī)模,此條標(biāo)準(zhǔn)通過代碼行數(shù)和貢獻(xiàn)者人數(shù)衡量;項(xiàng)目年限超過5年,保證并發(fā)缺陷具有足夠長的演進(jìn)歷史可供量化分析;項(xiàng)目活動(dòng)水平,通過一年內(nèi)代碼倉庫的提交次數(shù)衡量.

按照以上標(biāo)準(zhǔn),通過對(duì)表1中控制器相關(guān)數(shù)據(jù)的對(duì)比,選擇ODL和ONOS作為實(shí)例研究對(duì)象.選擇二者的其他優(yōu)勢包括:ODL和ONOS是目前較為典型的生產(chǎn)級(jí)開源SDN控制器[2],二者面對(duì)的主要目標(biāo)用戶不同,實(shí)現(xiàn)功能組件亦有所區(qū)別,一定程度上可以覆蓋相對(duì)較多應(yīng)用場景的SDN控制器并發(fā)缺陷特征.尤其是,ODL生態(tài)中包含了控制器和在控制器平臺(tái)上實(shí)現(xiàn)的不同功能的網(wǎng)絡(luò)應(yīng)用程序,可以認(rèn)為其缺陷倉庫包含了以控制器為核心的控制平面、數(shù)據(jù)平面和應(yīng)用平面在內(nèi)的歷史缺陷報(bào)告集合.由此保證了實(shí)例研究對(duì)象的代表性.

下面按照3.1節(jié)給出量化分析方法的框架,對(duì)實(shí)例研究對(duì)象進(jìn)行處理及分析.

按照圖1的步驟1進(jìn)行數(shù)據(jù)收集及預(yù)處理,通過Jira API自動(dòng)獲取ODL和ONOS可以公開訪問的歷史缺陷報(bào)告,進(jìn)行初步篩選統(tǒng)計(jì)的數(shù)據(jù)集信息如表4所示.其中,項(xiàng)目總體的缺陷修復(fù)率是指有明確解決方案的缺陷報(bào)告數(shù)/總?cè)毕輬?bào)告數(shù),ODL比ONOS的缺陷修復(fù)率低,主要因?yàn)槿毕菡w修復(fù)率與項(xiàng)目規(guī)模呈負(fù)相關(guān)關(guān)系[16].需要說明的是,雖然二者缺陷報(bào)告在絕對(duì)數(shù)量上有差距,但是量化分析更關(guān)心的是相對(duì)數(shù)量,并不會(huì)影響分析結(jié)果.

經(jīng)過了圖1的步驟2和步驟3,對(duì)有明確解決方案的缺陷報(bào)告進(jìn)行修復(fù)過程特征提取、關(guān)鍵字匹配、人工篩選以及分層隨機(jī)抽樣后的數(shù)據(jù)集樣本數(shù)量如表5所示.

表5 各篩選階段的缺陷報(bào)告數(shù)據(jù)集樣本數(shù)量Table 5 Number of bug report data set samples at each stage

在表5中,對(duì)用于分析的數(shù)據(jù)進(jìn)行了相應(yīng)的預(yù)處理,例如,將優(yōu)先級(jí)由文本映射為數(shù)字,根據(jù)不同粒度計(jì)算時(shí)間因素的度量,對(duì)于修復(fù)時(shí)間以“天”為粒度計(jì)算、對(duì)于回復(fù)延遲以“小時(shí)”為粒度計(jì)算等.

4.2 并發(fā)缺陷的量化分析

4.2.1 并發(fā)缺陷分類數(shù)據(jù)特征分析

本部分的量化分析結(jié)果可以回答RQ1,給出SDN 控制器在各類型并發(fā)缺陷和在各功能模塊之間的數(shù)據(jù)分布特征.對(duì)于所獲得的歷史缺陷報(bào)告數(shù)據(jù)集,統(tǒng)計(jì)不同分類下的頻數(shù)與頻率分布.ODL和ONOS所發(fā)生并發(fā)缺陷類型分布特征如表6 所示.

表6 歷史缺陷報(bào)告在并發(fā)缺陷類型的分布特征Table 6 Distribution of concurrent bugs for historical bug reports

基于表6給出的數(shù)據(jù),對(duì)5種類型的并發(fā)缺陷的實(shí)例分析如下:

1)原子性違背:一般是由于線程交錯(cuò)操作缺乏約束破壞了假定具有原子性的操作.例如,在 ODL中的OPNFLWPLUG-1075,由于破壞模型驅(qū)動(dòng)項(xiàng)目MD-SAL中事務(wù)寫操作的原子性導(dǎo)致了端口事件線程關(guān)閉.ODL使用Java的CAS(Compare and Swap)指令實(shí)現(xiàn)原子性,CAS 指令被看作是硬件鎖.ODL和ONOS中原子性違背的歷史缺陷數(shù)量較少且大多發(fā)生在項(xiàng)目初期.

2)順序違背:多個(gè)線程在同時(shí)執(zhí)行時(shí),未能按預(yù)期設(shè)計(jì)的順序進(jìn)行交互,出現(xiàn)了不正確交錯(cuò)執(zhí)行.在SDN控制器所涉及的相關(guān)協(xié)議實(shí)現(xiàn)中,為了加強(qiáng)事件之間的因果關(guān)系,事件排序是必要的.其中,典型的問題是在控制器和交換機(jī)的交互中寫(FLOW_MOD)和讀(PACKET_IN)發(fā)生了順序違背,交換機(jī)的轉(zhuǎn)發(fā)狀態(tài)可能會(huì)有很大的不同.例如,ODL的NETCONF協(xié)議項(xiàng)目中的NETCONF-93,多個(gè)配置通過一個(gè)會(huì)話異步發(fā)送,導(dǎo)致操作互相干擾,多個(gè)寫的提交操作出現(xiàn)了亂序的問題.而ONOS項(xiàng)目中出現(xiàn)的流表規(guī)則的提交順序沖突也屬于此類問題.

3)數(shù)據(jù)競爭:是由共享資源引發(fā),也包括共享數(shù)據(jù)庫,是2個(gè)實(shí)例項(xiàng)目中出現(xiàn)最多的并發(fā)缺陷類型,這也與現(xiàn)有研究的結(jié)論相符合[13].在SDN網(wǎng)絡(luò)中,特有的重要共享數(shù)據(jù)資源是流表,ODL提供兩種數(shù)據(jù)存儲(chǔ),配置存儲(chǔ)(config datastores)用于存儲(chǔ)用戶所需的狀態(tài),操作存儲(chǔ)(operational datastores)用于存儲(chǔ)實(shí)際的網(wǎng)絡(luò)狀態(tài).ONOS的共享數(shù)據(jù)庫是流規(guī)則存儲(chǔ)(FlowRulesStores).由于共享造成的數(shù)據(jù)競爭,可能發(fā)生在節(jié)點(diǎn)內(nèi)部,也可能發(fā)生在節(jié)點(diǎn)之間.例如,ODL項(xiàng)目中的BGPCEP-645,關(guān)閉對(duì)端并更新路由時(shí)發(fā)生對(duì)共享資源的競爭訪問.對(duì)于非死鎖類的并發(fā)缺陷,大多可以歸因于數(shù)據(jù)競爭,也是任何并發(fā)軟件系統(tǒng)中的基本問題.

4)死鎖:死鎖在2個(gè)實(shí)例項(xiàng)目中都有發(fā)生,ODL項(xiàng)目中發(fā)生的更多.例如,ODL項(xiàng)目中的CONTROLLER-1893,應(yīng)用程序線程出現(xiàn)了死鎖.在NETVIRT-424中出現(xiàn)了典型的ABBA死鎖,由于互斥鎖的粒度不恰當(dāng)(粒度較粗),與 MAC 相關(guān)流的互斥鎖在 ELAN + MAC 上的鎖定無法操作,解決方法是通過鎖定更細(xì)粒度的互斥鎖鎖定ELAN+MAC+DPID.SDN集群中會(huì)發(fā)生分布式死鎖,即每個(gè)節(jié)點(diǎn)都在等待以便其他節(jié)點(diǎn)進(jìn)行下一步操作,引發(fā)整個(gè)集群掛起.例如,ONOS-1965在Leader選舉過程中,候選節(jié)點(diǎn)重啟后沒有出現(xiàn)在候選列表中,引發(fā)了死鎖.

5)并發(fā)類型狀態(tài)缺陷:會(huì)使系統(tǒng)進(jìn)入不正確的狀態(tài).典型的是發(fā)生在SDN集群部署中,尤其是集群中的全局網(wǎng)絡(luò)狀態(tài)保存在多個(gè)同步的控制器中,并分散保存在數(shù)據(jù)平面的交換機(jī)中,如果出現(xiàn)并發(fā)類型狀態(tài)缺陷,會(huì)造成不同控制節(jié)點(diǎn)有不同的全局視圖的后果.在表6中,值得關(guān)注的是ONOS比ODL有更多的歷史并發(fā)類型狀態(tài)缺陷,這是因?yàn)镺NOS在設(shè)計(jì)之初即考慮了分布式的集群部署方式實(shí)現(xiàn),采用邏輯上集中控制實(shí)現(xiàn)分布式核心層.在ONOS缺陷管理工具中,報(bào)告者對(duì)于出現(xiàn)故障的表征更傾向于采用出現(xiàn)“狀態(tài)不一致”等文字描述,為了區(qū)別于4類典型并發(fā)缺陷,本文將這些缺陷歸類為并發(fā)類型狀態(tài)缺陷.例如,ONOS-4515中的數(shù)據(jù)平面轉(zhuǎn)發(fā)設(shè)備角色在3個(gè)集群節(jié)點(diǎn)間不同步,其中1個(gè)節(jié)點(diǎn)看到角色為“none”的5臺(tái)轉(zhuǎn)發(fā)設(shè)備,另外2個(gè)節(jié)點(diǎn)看到角色為“standby”的5臺(tái)轉(zhuǎn)發(fā)設(shè)備.為了讓SDN控制器網(wǎng)絡(luò)正常運(yùn)行,這些集群節(jié)點(diǎn)的狀態(tài)必須是一致的.

對(duì)于并發(fā)缺陷在功能模塊上的數(shù)量分布,由于ODL生態(tài)中包含了以控制器為核心的3個(gè)平面的缺陷報(bào)告集合,以O(shè)DL為例進(jìn)行分析.ODL控制器采用模塊化的設(shè)計(jì),不同子項(xiàng)目一般代表不同的功能模塊.參考ODL官方網(wǎng)站的信息(3)https://www.opendaylight.org,2021-04和現(xiàn)有研究[5],對(duì)ODL進(jìn)行功能模塊劃分,給出SDN控制器并發(fā)缺陷在功能模塊上的數(shù)量分布,如圖2所示.

圖2 ODL歷史并發(fā)缺陷在功能模塊上的分布特征Fig.2 Distribution of ODL historical concurrency bugs on functional modules

由圖2可以發(fā)現(xiàn),南向接口插件和控制器核心功能的并發(fā)缺陷數(shù)量較多.在SDN控制平面和數(shù)據(jù)平面南向交互過程中涉及了多個(gè)協(xié)議,如OVSDB、NETCONF和POF等,而使用協(xié)議通信實(shí)現(xiàn)平面間的交互,增加、修改、刪除和查看轉(zhuǎn)發(fā)設(shè)備的配置和狀態(tài)信息,對(duì)應(yīng)了多線程實(shí)現(xiàn)中的讀和寫操作,容易引入并發(fā)缺陷.在與傳統(tǒng)網(wǎng)絡(luò)互聯(lián)的南向插件中,發(fā)生死鎖的情況使最多的,并且主要發(fā)生在3層網(wǎng)絡(luò)路由的相關(guān)功能中.另外,控制器通過南向協(xié)議下發(fā)配置策略中出現(xiàn)的并發(fā)缺陷同樣較為典型.例如,在通過NETCONF配置網(wǎng)絡(luò)的過程中,NETCONF-58只通過REST操作,當(dāng)刪除和初始化連續(xù)發(fā)生時(shí),出現(xiàn)了事務(wù)鏈上的數(shù)據(jù)競爭,導(dǎo)致事務(wù)鏈?zhǔn)?解決方法是修改操作的邏輯順序,首先應(yīng)該刪除配置而不是立即替換它,即,修改 POST>PUT 為POST>DELETE>POST.北向應(yīng)用出現(xiàn)并發(fā)缺陷的數(shù)據(jù)較少,主要是基于意圖通過流編程實(shí)現(xiàn)網(wǎng)絡(luò)配置更新過程中出現(xiàn)的順序違背(GBP-288).另外,在集群部署情況下,對(duì)于以多控制器為中心的東西向分布式協(xié)議的交互中,ODL具有多任務(wù)并發(fā)的特性,因此出現(xiàn)并發(fā)缺陷相關(guān)的問題主要是在核心控制器功能模塊的集群(clustering)組件中.

通過以上分析發(fā)現(xiàn):數(shù)據(jù)競爭仍是SDN控制器中最常出現(xiàn)的并發(fā)缺陷類型;由于分布式的部署方式,ONOS控制器中并發(fā)類型狀態(tài)缺陷出現(xiàn)較多;ODL控制器中南向接口插件和控制器核心功能的并發(fā)缺陷數(shù)量較多,集群組件是發(fā)現(xiàn)并發(fā)缺陷過程中值得關(guān)注的組件.

4.2.2 并發(fā)缺陷修復(fù)特征量化分析

本部分給出的數(shù)據(jù)和分析可以回答RQ2,給出SDN控制器并發(fā)缺陷的修復(fù)過程特征的分析,以及并發(fā)與非并發(fā)缺陷在修復(fù)過程特征上的區(qū)別分析.表7給出了在修復(fù)過程度量上的量化分析結(jié)果,包括:并發(fā)缺陷數(shù)據(jù)(CD)和非并發(fā)缺陷數(shù)據(jù)(NCD)集中趨勢分析的測度值,每個(gè)修復(fù)過程度量的分布在并發(fā)缺陷和非并發(fā)缺陷兩個(gè)分類上的Mann-Whitney U檢驗(yàn)的漸進(jìn)顯著性結(jié)果p值.為了可讀性和避免異常值,在計(jì)算統(tǒng)計(jì)值時(shí),去掉0值的影響,并且僅統(tǒng)計(jì)度量值是離散型數(shù)據(jù)(例如n_node)的眾數(shù).

表7 SDN控制器并發(fā)缺陷修復(fù)特征量化統(tǒng)計(jì)信息Table 7 Descriptive statistics of concurrency bugs for SDN controllers

通過定量方法來調(diào)查SDN控制器軟件中并發(fā)和非并發(fā)缺陷在修復(fù)過程的異同.對(duì)于表7具體分析如下:

1)時(shí)間因素的分析.與預(yù)先的設(shè)想并不相同,SDN控制器中修復(fù)并發(fā)缺陷和非并發(fā)缺陷所投入時(shí)長的區(qū)別并不明顯.相比其他軟件,如Apache、ZooKeeper、 Spark 等開源軟件中并發(fā)錯(cuò)誤平均修復(fù)時(shí)間(82天)[13],SDN控制器的并發(fā)缺陷的平均修復(fù)時(shí)間是66天左右,需要的修復(fù)時(shí)間更短.對(duì)于反映互動(dòng)頻率的度量t_acomm,雖然p=0.054,區(qū)別并不顯著,但是通過集中趨勢分析的測度值可以發(fā)現(xiàn),相對(duì)非并發(fā)缺陷而言,并發(fā)缺陷的平均討論時(shí)間間隔更短,報(bào)告者和開發(fā)者互動(dòng)的頻率相對(duì)更高,對(duì)于SDN控制器,修復(fù)并發(fā)缺陷并不容易,需要通頻繁互動(dòng)補(bǔ)充必要的信息,例如觸發(fā)缺陷的配置及操作,可能的根因的討論等.

2)缺陷影響的分析.對(duì)于并發(fā)缺陷和非并發(fā)缺陷,影響節(jié)點(diǎn)數(shù)的度量n_node的區(qū)別顯著(p?0.05),因此,主要分析并發(fā)缺陷所影響的節(jié)點(diǎn)數(shù)目.SDN網(wǎng)絡(luò)中,在測試或生產(chǎn)部署的過程中,包括單控制器節(jié)點(diǎn)部署和控制器集群部署兩種方式.單控制器節(jié)點(diǎn)在開發(fā)測試階段比較常見,生產(chǎn)環(huán)境中多以集群方式進(jìn)行部署.并發(fā)缺陷影響的節(jié)點(diǎn)數(shù)目可以分為不同的情形:①只發(fā)生在單個(gè)SDN控制器節(jié)點(diǎn),尤其是在連接多臺(tái)交換機(jī)的單控制器擴(kuò)展性測試中出現(xiàn)并發(fā)缺陷的情形出現(xiàn)較多;②只發(fā)生在集群中,例如,BGPCEP-442是發(fā)生在集群(3節(jié)點(diǎn))中的數(shù)據(jù)競爭;③在單節(jié)點(diǎn)和集群中均發(fā)生,這類缺陷出現(xiàn)的情形最為普遍.但是受限于數(shù)據(jù)集來自于開發(fā)階段的SDN控制器,節(jié)點(diǎn)觸發(fā)范圍的規(guī)模較小:多為1個(gè)節(jié)點(diǎn)(表7中眾數(shù)為1);涉及到控制器集群,多為3個(gè)節(jié)點(diǎn),例如,在ODL關(guān)于集群的并發(fā)缺陷報(bào)告中,以3節(jié)點(diǎn)集群測試?yán)鶊?bào)告的缺陷為主;最大為7個(gè)節(jié)點(diǎn)的情形.對(duì)于ONOS,在集群部署的情況下,即使一個(gè)缺陷只出現(xiàn)在一個(gè)節(jié)點(diǎn)上,它也會(huì)將其影響傳播到其他節(jié)點(diǎn)或組件,從而導(dǎo)致集群的一部分或整個(gè)集群失敗.對(duì)于非并發(fā)缺陷,節(jié)點(diǎn)數(shù)的影響并不明顯,集中趨勢分析中的多個(gè)測度值為0.

3)重要性和復(fù)雜度的分析.并發(fā)缺陷和非并發(fā)缺陷在優(yōu)先級(jí)上的區(qū)別并不顯著,但是在文本長度和評(píng)論數(shù)上均區(qū)別顯著(p?0.05),并發(fā)缺陷仍然是SDN控制器項(xiàng)目投入更多關(guān)注的缺陷類型.

4)修復(fù)影響的分析.從表7中可以看到,在所給出的2個(gè)度量上,兩組數(shù)據(jù)均區(qū)別顯著.與修復(fù)非并發(fā)性缺陷相比,修復(fù)并發(fā)缺陷明顯涉及更多的補(bǔ)丁,有更多的修復(fù)影響版本,明顯需要開發(fā)者投入更多工作量進(jìn)行修復(fù).

在SDN控制器中由于各平面的分離和分布式的部署方式,并發(fā)缺陷仍然需要關(guān)注.通過對(duì)比分析發(fā)現(xiàn):并發(fā)缺陷在修復(fù)過程中,需要通過配置特定節(jié)點(diǎn)數(shù)目的SDN控制器才能夠復(fù)現(xiàn);雖然并發(fā)缺陷并沒有賦予更高的優(yōu)先級(jí),但是需要開發(fā)人員投入更多工作量進(jìn)行復(fù)現(xiàn)并修復(fù).這些發(fā)現(xiàn)可以為并發(fā)缺陷檢測和修復(fù)提供有用的指南.

4.3 有效性分析

對(duì)于實(shí)證研究需要討論數(shù)據(jù)身來源是否真實(shí)可靠的有效性以及所得結(jié)論是否具有推廣價(jià)值的有效性[21].由于所研究的缺陷是經(jīng)過真實(shí)項(xiàng)目的開發(fā)團(tuán)隊(duì)成員的確認(rèn),設(shè)置狀態(tài)為“已關(guān)閉”或“已解決”的缺陷,并通過與提交代碼記錄的交叉對(duì)比,因此認(rèn)為是可以真實(shí)地反映實(shí)際缺陷情況的;其次,研究只關(guān)注ODL和ONOS兩個(gè)SDN控制器項(xiàng)目的缺陷數(shù)據(jù)量的相對(duì)關(guān)系,從這個(gè)意義上說,在一定程度上可以屏蔽在代碼規(guī)模和功能復(fù)雜程度的差異;第三,對(duì)于并發(fā)缺陷,基于關(guān)鍵字的搜索可能會(huì)遺漏一些真正的并發(fā)缺陷,但不包含任何所選關(guān)鍵字的并發(fā)缺陷報(bào)告極有可能沒有包含完整信息,對(duì)分析而言沒有用;第四,如4.1節(jié)所述,所選擇實(shí)例分析SDN控制器項(xiàng)目具有代表性,但是,由于ODL和ONOS是開源項(xiàng)目,研究結(jié)果可能不適用于閉源的SDN控制器項(xiàng)目,未來,需要更多的數(shù)據(jù)來支撐更可靠的結(jié)論.

5 結(jié) 語

本文提出了SDN控制器軟件并發(fā)缺陷量化分析方法框架,對(duì)SDN控制器軟件的并發(fā)缺陷進(jìn)行了實(shí)證量化分析.所提出的量化分析框架并不依賴于具體的SDN控制器軟件,因此方法具有一定的通用性,可以用于或適應(yīng)其他軟件系統(tǒng).基于軟件缺陷生命周期給出了4個(gè)維度10個(gè)具體度量作為并發(fā)缺陷修復(fù)過程的評(píng)估指標(biāo).采用統(tǒng)計(jì)學(xué)中的量化分析方法研究了SDN控制器并發(fā)性缺陷在不同類型并發(fā)缺陷和功能模塊的分布特征以及在所給出的修復(fù)過程度量所表現(xiàn)特征,可以為SDN控制器平臺(tái)使用者和基于平臺(tái)進(jìn)行應(yīng)用開發(fā)的開發(fā)者提供一個(gè)新的視角理解SDN控制器中出現(xiàn)的并發(fā)缺陷.也可以為SDN控制器的部署和后期維護(hù)提供便利支持更好地管理控制器應(yīng)用軟件產(chǎn)品,改善SDN控制器平臺(tái)的并發(fā)缺陷修復(fù)過程.