考慮這麼一個(gè)伺服器,它可以處理來(lái)自多個(gè)客戶端的服務(wù)請(qǐng)求(Request),為了不丟失客戶的請(qǐng)求,它要維持一個(gè)緩衝區(qū),客戶的請(qǐng)求會(huì)先儲(chǔ)存至緩衝區(qū)中,而伺服器會(huì)從緩衝區(qū)中取出請(qǐng)求並執(zhí)行,如果緩衝區(qū)中沒(méi)有請(qǐng)求,則伺服器就等待,直到被通知有新的請(qǐng)求存入緩衝區(qū)中,伺服器再度進(jìn)行請(qǐng)求的執(zhí)行。
關(guān)於這個(gè)描述的一個(gè)簡(jiǎn)單 UML 順序圖如下所示:

首先要考慮到,緩衝區(qū)會(huì)同時(shí)被兩個(gè)以上的執(zhí)行緒進(jìn)行存取,即伺服器的請(qǐng)求處理執(zhí)行緒與客戶端執(zhí)行緒,所以必須對(duì)緩衝區(qū)進(jìn)行防護(hù)。
再來(lái)是當(dāng)緩衝區(qū)中沒(méi)有請(qǐng)求時(shí),伺服器必須等待直到被通知有新的請(qǐng)求。
Guarded Suspension模式關(guān)注的是執(zhí)行的流程架構(gòu),以Java來(lái)實(shí)現(xiàn)這個(gè)架構(gòu)的話如下所示:
一個(gè)例子是多人聊天伺服器,請(qǐng)求可能只是一個(gè)客戶端送出的聊天訊息,聊天訊息會(huì)先存至緩衝區(qū)中,伺服器會(huì)不斷的從緩衝區(qū)中取出聊天訊息並發(fā)給客戶端,如果緩衝區(qū)中沒(méi)有新訊息,則伺服器就進(jìn)入等待,直到有一個(gè)客戶端發(fā)出聊天訊息並存入緩衝區(qū)中,此時(shí)伺服器再度被通知,然後再度取出訊息並進(jìn)行發(fā)送。
關(guān)於這個(gè)描述的一個(gè)簡(jiǎn)單 UML 順序圖如下所示:

首先要考慮到,緩衝區(qū)會(huì)同時(shí)被兩個(gè)以上的執(zhí)行緒進(jìn)行存取,即伺服器的請(qǐng)求處理執(zhí)行緒與客戶端執(zhí)行緒,所以必須對(duì)緩衝區(qū)進(jìn)行防護(hù)。
再來(lái)是當(dāng)緩衝區(qū)中沒(méi)有請(qǐng)求時(shí),伺服器必須等待直到被通知有新的請(qǐng)求。
Guarded Suspension模式關(guān)注的是執(zhí)行的流程架構(gòu),以Java來(lái)實(shí)現(xiàn)這個(gè)架構(gòu)的話如下所示:
- RequestQueue.java
public class RequestQueue {
private java.util.LinkedList queue;
public RequestQueue() {
queue = new java.util.LinkedList();
}
public synchronized Request getRequest() {
while(queue.size() <= 0) {
try {
wait();
}
catch(InterruptedException e) {}
}
return (Request) queue.removeFirst();
}
public synchronized void putRequest(Request request) {
queue.addLast(request);
notifyAll();
}
}
一個(gè)例子是多人聊天伺服器,請(qǐng)求可能只是一個(gè)客戶端送出的聊天訊息,聊天訊息會(huì)先存至緩衝區(qū)中,伺服器會(huì)不斷的從緩衝區(qū)中取出聊天訊息並發(fā)給客戶端,如果緩衝區(qū)中沒(méi)有新訊息,則伺服器就進(jìn)入等待,直到有一個(gè)客戶端發(fā)出聊天訊息並存入緩衝區(qū)中,此時(shí)伺服器再度被通知,然後再度取出訊息並進(jìn)行發(fā)送。