東坡下載:內(nèi)容最豐富最安全的下載站!

首頁編程開發(fā)Java → 多線程開發(fā)的捷徑:構(gòu)建Java并發(fā)模型框架

多線程開發(fā)的捷徑:構(gòu)建Java并發(fā)模型框架

相關(guān)文章發(fā)表評論 來源:本站時間:2010/10/14 12:04:04字體大。A-A+

更多

作者:東坡下載點擊:528次評論:0次標(biāo)簽:

Java多線程特性為構(gòu)建高性能的應(yīng)用提供了極大的方便,但是也帶來了不少的麻煩。線程間同步、數(shù)據(jù)一致性等煩瑣的問題需要細(xì)心的考慮,一不小心就會出現(xiàn)一些微妙的,難以調(diào)試的錯誤。

  另外,應(yīng)用邏輯和線程邏輯糾纏在一起,會導(dǎo)致程序的邏輯結(jié)構(gòu)混亂,難以復(fù)用和維護。本文試圖給出一個解決這個問題的方案,通過構(gòu)建一個并發(fā)模型框架(framework),使得開發(fā)多線程的應(yīng)用變得容易。

  基礎(chǔ)知識

  Java語言提供了對于線程很好的支持,實現(xiàn)方法小巧、優(yōu)雅。對于方法重入的保護,信號量(semaphore)和臨界區(qū)(critical section)機制的實現(xiàn)都非常簡潔?梢院苋菀椎膶崿F(xiàn)多線程間的同步操作從而保護關(guān)鍵數(shù)據(jù)的一致性。這些特點使得Java成為面向?qū)ο笳Z言中對于多線程特性支持方面的佼佼者(C++正在試圖把boost庫中的對于線程的支持部分納入語言標(biāo)準(zhǔn))。

  Java中內(nèi)置了對于對象并發(fā)訪問的支持,每一個對象都有一個監(jiān)視器(monitor),同時只允許一個線程持有監(jiān)視器從而進行對對象的訪問,那些沒有獲得監(jiān)視器的線程必須等待直到持有監(jiān)視器的線程釋放監(jiān)視器。對象通過synchronized關(guān)鍵字來聲明線程必須獲得監(jiān)視器才能進行對自己的訪問。

  synchronized聲明僅僅對于一些較為簡單的線程間同步問題比較有效,對于哪些復(fù)雜的同步問題,比如帶有條件的同步問題,Java提供了另外的解決方法,wait/notify/notifyAll。

  獲得對象監(jiān)視器的線程可以通過調(diào)用該對象的wait方法主動釋放監(jiān)視器,等待在該對象的線程等待隊列上,此時其他線程可以得到監(jiān)視器從而訪問該對象,之后可以通過調(diào)用notify/notifyAll方法來喚醒先前因調(diào)用wait方法而等待的線程。

  一般情況下,對于wait/notify/notifyAll方法的調(diào)用都是根據(jù)一定的條件來進行的,比如:經(jīng)典的生產(chǎn)者/消費者問題中對于隊列空、滿的判斷。熟悉POSIX的讀者會發(fā)現(xiàn),使用wait/notify/notifyAll可以很容易的實現(xiàn)POSIX中的一個線程間的高級同步技術(shù):條件變量。

  簡單例子

  本文將圍繞一個簡單的例子展開論述,這樣可以更容易突出我們解決問題的思路、方法。本文想向讀者展現(xiàn)的正是這些思路、方法。這些思路、方法更加適用于解決大規(guī)模、復(fù)雜應(yīng)用中的并發(fā)問題?紤]一個簡單的例子,我們有一個服務(wù)提供者,它通過一個接口對外提供服務(wù),服務(wù)內(nèi)容非常簡單,就是在標(biāo)準(zhǔn)輸出上打印Hello World。類結(jié)構(gòu)圖如下:

類結(jié)構(gòu)圖

  代碼如下:

  1.interface Service

  2.{

  3.    public void sayHello();

  4.}

  5.class ServiceImp implements Service

  6.{

  7.    public void sayHello() {

  8.        System.out.println("Hello World!");

  9.    }

  10.}

  11.class Client

  12.{

  13.    public Client(Service s) {

  14.        _service = s;

  15.}

  16.    public void requestService() {

  17.        _service.sayHello();

  18.    }

  19.    private Service _service;

  20.}

  如果現(xiàn)在有新的需求,要求該服務(wù)必須支持Client的并發(fā)訪問。一種簡單的方法就是在ServicImp類中的每個方法前面加上synchronized聲明,來保證自己內(nèi)部數(shù)據(jù)的一致性(當(dāng)然對于本例來說,目前是沒有必要的,因為ServiceImp沒有需要保護的數(shù)據(jù),但是隨著需求的變化,以后可能會有的)。但是這樣做至少會存在以下幾個問題:

  1.現(xiàn)在要維護ServiceImp的兩個版本:多線程版本和單線程版本(有些地方,比如其他項目,可能沒有并發(fā)的問題),容易帶來同步更新和正確選擇版本的問題,給維護帶來麻煩。

  2.如果多個并發(fā)的Client頻繁調(diào)用該服務(wù),由于是直接同步調(diào)用,會造成Client阻塞,降低服務(wù)質(zhì)量。

  3.很難進行一些靈活的控制,比如:根據(jù)Client的優(yōu)先級進行排隊等等。

  4.這些問題對于大型的多線程應(yīng)用服務(wù)器尤為突出,對于一些簡單的應(yīng)用(如本文中的例子)可能根本不用考慮。本文正是要討論這些問題的解決方案,文中的簡單的例子只是提供了一個說明問題,展示思路、方法的平臺。

  5.如何才能較好的解決這些問題,有沒有一個可以重用的解決方案呢?讓我們先把這些問題放一放,先來談?wù)労涂蚣苡嘘P(guān)的一些問題。

  框架概述

  熟悉面向?qū)ο蟮淖x者一定知道面向?qū)ο蟮淖畲蟮膬?yōu)勢之一就是:軟件復(fù)用。通過復(fù)用,可以減少很多的工作量,提高軟件開發(fā)生產(chǎn)率。復(fù)用本身也是分層次的,代碼級的復(fù)用和設(shè)計架構(gòu)的復(fù)用。

  大家可能非常熟悉C語言中的一些標(biāo)準(zhǔn)庫,它們提供了一些通用的功能讓你的程序使用。但是這些標(biāo)準(zhǔn)庫并不能影響你的程序結(jié)構(gòu)和設(shè)計思路,僅僅是提供一些機能,幫助你的程序完成工作。它們使你不必重頭編寫一般性的通用功能(比如printf),它們強調(diào)的是程序代碼本身的復(fù)用性,而不是設(shè)計架構(gòu)的復(fù)用性。

  那么什么是框架呢?所謂框架,它不同于一般的標(biāo)準(zhǔn)庫,是指一組緊密關(guān)聯(lián)的(類)classes,強調(diào)彼此的配合以完成某種可以重復(fù)運用的設(shè)計概念。這些類之間以特定的方式合作,彼此不可或缺。它們相當(dāng)程度的影響了你的程序的形貌?蚣鼙旧硪(guī)劃了應(yīng)用程序的骨干,讓程序遵循一定的流程和動線,展現(xiàn)一定的風(fēng)貌和功能。這樣就使程序員不必費力于通用性的功能的繁文縟節(jié),集中精力于專業(yè)領(lǐng)域。

  有一點必須要強調(diào),放之四海而皆準(zhǔn)的框架是不存在的,也是最沒有用處的?蚣芡际轻槍δ硞特定應(yīng)用領(lǐng)域的,是在對這個應(yīng)用領(lǐng)域進行深刻理解的基礎(chǔ)上,抽象出該應(yīng)用的概念模型,在這些抽象的概念上搭建的一個模型,是一個有形無體的框架。不同的具體應(yīng)用根據(jù)自身的特點對框架中的抽象概念進行實現(xiàn),從而賦予框架生命,完成應(yīng)用的功能。

  基于框架的應(yīng)用都有兩部分構(gòu)成:框架部分和特定應(yīng)用部分。要想達到框架復(fù)用的目標(biāo),必須要做到框架部分和特定應(yīng)用部分的隔離。使用面向?qū)ο蟮囊粋強大功能:多態(tài),可以實現(xiàn)這一點。在框架中完成抽象概念之間的交互、關(guān)聯(lián),把具體的實現(xiàn)交給特定的應(yīng)用來完成。其中一般都會大量使用了Template Method設(shè)計模式。Java中的Collection Framework以及微軟的MFC都是框架方面很好的例子。有興趣的讀者可以自行研究。

構(gòu)建框架

  如何構(gòu)建一個Java并發(fā)模型框架呢?讓我們先回到原來的問題,先來分析一下原因。造成要維護多線程和單線程兩個版本的原因是由于把應(yīng)用邏輯和并發(fā)邏輯混在一起,如果能夠做到把應(yīng)用邏輯和并發(fā)模型進行很好的隔離,那么應(yīng)用邏輯本身就可以很好的被復(fù)用,而且也很容易把并發(fā)邏輯添加進來而不會對應(yīng)用邏輯造成任何影響。造成Client阻塞,性能降低以及無法進行額外的控制的原因是由于所有的服務(wù)調(diào)用都是同步的,解決方案很簡單,改為異步調(diào)用方式,把服務(wù)的調(diào)用和服務(wù)的執(zhí)行分離。

  首先來介紹一個概念,活動對象(Active Object)。所謂活動對象是相對于被動對象(passive object)而言的,被動對象的方法的調(diào)用和執(zhí)行都是在同一個線程中的,被動對象方法的調(diào)用是同步的、阻塞的,一般的對象都屬于被動對象;主動對象的方法的調(diào)用和執(zhí)行是分離的,主動對象有自己獨立的執(zhí)行線程,主動對象的方法的調(diào)用是由其他線程發(fā)起的,但是方法是在自己的線程中執(zhí)行的,主動對象方法的調(diào)用是異步的,非阻塞的。

  本框架的核心就是使用主動對象來封裝并發(fā)邏輯,然后把Client的請求轉(zhuǎn)發(fā)給實際的服務(wù)提供者(應(yīng)用邏輯),這樣無論是Client還是實際的服務(wù)提供者都不用關(guān)心并發(fā)的存在,不用考慮并發(fā)所帶來的數(shù)據(jù)一致性問題。從而實現(xiàn)應(yīng)用邏輯和并發(fā)邏輯的隔離,服務(wù)調(diào)用和服務(wù)執(zhí)行的隔離。下面給出關(guān)鍵的實現(xiàn)細(xì)節(jié)。

  本框架有如下幾部分構(gòu)成:

  1.一個ActiveObject類,從Thread繼承,封裝了并發(fā)邏輯的活動對象;

  2.一個ActiveQueue類,主要用來存放調(diào)用者請求;

  3.一個MethodRequest接口,主要用來封裝調(diào)用者的請求,Command設(shè)計模式的一種實現(xiàn)方式。它們的一個簡單的實現(xiàn)如下:

  1. //MethodRequest接口定義

  2.  interface MethodRequest

  3.{

  4.    public void call();

  5.}

  6.//ActiveQueue定義,其實就是一個producer/consumer隊列

  7.    class ActiveQueue

  8.{

  9.      public ActiveQueue() {

  10.        _queue = new Stack();

  11.      }

  12.    public synchronized void enqueue(MethodRequest mr) {

  13.        while(_queue.size() > QUEUE_SIZE) {

  14.            try {

  15.                   wait();

  16.            }catch (InterruptedException e) {

  17.                   e.printStackTrace();

  18.            }

  19.        }

  20.

  21.        _queue.push(mr);

  22.        notifyAll();

  23.        System.out.println("Leave Queue");

  24.    }

  25.    public synchronized MethodRequest dequeue() {

  26.        MethodRequest mr;

  27.

  28.        while(_queue.empty()) {

  29.            try {

  30.                wait();

  31.            }catch (InterruptedException e) {

  32.                e.printStackTrace();

  33.            }

  34.        }

  35.        mr = (MethodRequest)_queue.pop();

  36.        notifyAll();

  37.

  38. return mr;

  39.    }

  40.    private Stack _queue;

  41.    private final static int QUEUE_SIZE = 20;

  42.}

  43.//ActiveObject的定義

  44.class ActiveObject extends Thread

  45.{

  46.    public ActiveObject() {

  47.        _queue = new ActiveQueue();

  48.        start();

  49.    }

  50.    public void enqueue(MethodRequest mr) {

  51.        _queue.enqueue(mr);

  52.    }

  53.    public void run() {

  54.        while(true) {

  55.            MethodRequest mr = _queue.dequeue();

  56.            mr.call();

  57.        }

  58.    }

  59.    private ActiveQueue _queue;

  60.}

  通過上面的代碼可以看出正是這些類相互合作完成了對并發(fā)邏輯的封裝。開發(fā)者只需要根據(jù)需要實現(xiàn)MethodRequest接口,另外再定義一個服務(wù)代理類提供給使用者,在服務(wù)代理者類中把服務(wù)調(diào)用者的請求轉(zhuǎn)化為MethodRequest實現(xiàn),交給活動對象即可。

  使用該框架,可以較好的做到應(yīng)用邏輯和并發(fā)模型的分離,從而使開發(fā)者集中精力于應(yīng)用領(lǐng)域,然后平滑的和并發(fā)模型結(jié)合起來,并且可以針對ActiveQueue定制排隊機制,比如基于優(yōu)先級等。

基于框架的解決方案

  本小節(jié)將使用上述的框架重新實現(xiàn)前面的例子,提供對于并發(fā)的支持。第一步先完成對于MethodRequest的實現(xiàn),對于我們的例子來說實現(xiàn)如下:

  1.class SayHello implements MethodRequest

  2.{

  3.    public SayHello(Service s) {

  4.        _service = s;

  5.    }

  6.    public void call() {

  7.        _service.sayHello();

  8.    }

  9.    private Service _service;

  10.}

  該類完成了對于服務(wù)提供接口sayHello方法的封裝。接下來定義一個服務(wù)代理類,來完成請求的封裝、排隊功能,當(dāng)然為了做到對Client透明,該類必須實現(xiàn)Service接口。定義如下:

  11.class ServiceProxy implements Service

  12.{

  13.    public ServiceProxy() {

  14.        _service = new ServiceImp();

  15.        _active_object = new ActiveObject();

  16.    }

  17.

  18.    public void sayHello() {

  19.        MethodRequest mr = new SayHello(_service);

  20.        _active_object.enqueue(mr);

  21.    }

  22.    private Service _service;

  23.    private ActiveObject _active_object;

  24.}

  其他的類和接口定義不變,下面對比一下并發(fā)邏輯增加前后的服務(wù)調(diào)用的變化,并發(fā)邏輯增加前,對于sayHello服務(wù)的調(diào)用方法:

  25.Service s = new ServiceImp();

  26.Client c = new Client(s);

  27.c.requestService();

  并發(fā)邏輯增加后,對于sayHello服務(wù)的調(diào)用方法:

  28.Service s = new  ServiceProxy();

  29.Client c = new Client(s);

  30.c.requestService();

  可以看出并發(fā)邏輯增加前后對于Client的ServiceImp都無需作任何改變,使用方式也非常一致,ServiceImp也能夠獨立的進行重用。類結(jié)構(gòu)圖如下:

類結(jié)構(gòu)圖

  讀者容易看出,使用框架也增加了一些復(fù)雜性,對于一些簡單的應(yīng)用來說可能根本就沒有必要使用本框架。希望讀者能夠根據(jù)自己的實際情況進行判斷。

  結(jié)論

  本文圍繞一個簡單的例子論述了如何構(gòu)架一個Java并發(fā)模型框架,其中使用了一些構(gòu)建框架的常用技術(shù),當(dāng)然所構(gòu)建的框架和一些成熟的商用框架相比,顯得非常稚嫩,比如沒有考慮服務(wù)調(diào)用有返回值的情況,但是其思想方法是一致的,希望讀者能夠深加領(lǐng)會,這樣無論對于構(gòu)建自己的框架還是理解一些其他的框架都是很有幫助的。讀者可以對本文中的框架進行擴充,直接應(yīng)用到自己的工作中。

  優(yōu)點:

  1.增強了應(yīng)用的并發(fā)性,簡化了同步控制的復(fù)雜性;

  2.服務(wù)的請求和服務(wù)的執(zhí)行分離,使得可以對服務(wù)請求排隊,進行靈活的控制;

  3.應(yīng)用邏輯和并發(fā)模型分離,使得程序結(jié)構(gòu)清晰,易于維護、重用;

  4.可以使開發(fā)者集中精力于應(yīng)用領(lǐng)域。

  缺點:

  1.由于框架所需類的存在,在一定程度上增加了程序的復(fù)雜性;

  2.如果應(yīng)用需要過多的活動對象,由于線程切換開銷會造成性能下降;

  3.可能會造成調(diào)試?yán)щy。

相關(guān)評論

閱讀本文后您有什么感想? 已有 人給出評價!

  • 2791 喜歡喜歡
  • 2101 頂
  • 800 難過難過
  • 1219 囧
  • 4049 圍觀圍觀
  • 5602 無聊無聊
熱門評論
最新評論
發(fā)表評論 查看所有評論(0)
昵稱:
表情: 高興 可 汗 我不要 害羞 好 下下下 送花 屎 親親
字?jǐn)?shù): 0/500 (您的評論需要經(jīng)過審核才能顯示)