JAVA 개발 시 실제 상태 의존성 관리를 위한 블로킹 큐 구현-java지도 시간-php.cn

클래스 라이브러리 자체에는 상태 종속성을 갖는 많은 클래스가 포함되어 있습니다. FutureTask, BlockingQueue 등과 같은 이러한 클래스의 일부 작업은 상태 전제 조건을 기반으로 합니다. 예를 들어, 빈 대기열에서 요소를 삭제하거나 완료되지 않은 작업의 계산 결과를 얻을 수 없습니다. 이 두 작업을 실행하기 전에 대기열이 비어 있지 않은 상태로 들어가거나 작업이 완료됨 상태로 들어갈 때까지 기다려야 합니다. 상태 의존 클래스를 생성하는 가장 간단한 방법은 클래스 라이브러리를 기반으로 생성하는 것입니다. 그러나 클래스 라이브러리에 원하는 기능이 없으면 Java 언어 및 클래스 라이브러리에서 제공하는 기본 메커니즘을 사용하여 고유한 동기화 메커니즘을 구성할 수도 있습니다.

그래서 이번 글에서는 자신만의 상태 의존성 클래스를 구성하는 방법을 소개하겠습니다. 가장 간단한 공사부터 복잡하고 표준화된 공사까지 단계별로 소개하여 그 과정과 최종 결과를 얻는 방법을 이해합니다.

상태 종속성 관리

차단 가능한 상태 종속성 작업은 다음 의사 코드에 표시됩니다.

acquire lock on object state //首先获取锁
     while (precondition does not hold) { //前提条件是否满足，不满足则一直循环重试
        release lock //释放锁
        wait until precondition might hold  //等待知道满足前提条件
        optionally fail if interrupted or timeout expire //中断或者超时，各种异常
        reacquire lock //重新获取锁
    }

perform action //执行任务
release lock  //释放锁

로그인 후 복사

잠금을 획득하고 조건이 충족되는지 확인합니다. 그렇지 않으면 잠금을 해제하고 조건이 충족될 때까지 차단 상태로 들어갑니다. 또는 중단되었거나 시간이 초과되었습니다. 기다렸다가 잠금을 다시 획득하세요. 작업을 실행하고 잠금을 해제합니다.

지금 이 의사코드를 보면 직관적으로 이해하지 못할 수도 있습니다. 이 글을 읽고 나면 이것이 무엇을 의미하는지 알게 될 것입니다.

ArrayBlockingQueue는 Put과 Take라는 두 가지 작업을 제공하는 제한된 캐시입니다. 여기에는 모두 전제 조건이 포함되어 있습니다. 요소는 전체 캐시에 배치될 수 없으며 요소는 빈 캐시에서 검색될 수 없습니다. 음, 우리의 목표는 그러한 ArrayBlockingQueue를 구성하는 것입니다.

다음으로 전제 조건이 충족되지 않는 상황을 처리하기 위해 서로 다른 방법을 사용하는 두 가지 제한된 캐시 구현을 소개합니다.

먼저 다음 기본 클래스 BaseBoundeBuffer를 살펴보겠습니다. 이후 구현에서는 이 기본 클래스를 확장합니다. 배열 기반의 순환 캐시이며, 포함된 변수 buf, head, tail, count는 캐시에 내장된 잠금 장치로 보호됩니다. 또한 동기식 doPut 및 doTake 메서드를 제공하며 하위 클래스에서 put 및 take 작업은 이러한 메서드를 통해 구현되며 기본 상태는 하위 클래스에서 숨겨집니다.

public abstract class BaseBoundedBuffer<V> {

    private final V[] buf;    
    private int tail;    
    private int head;    
    private int count;    
    protected BaseBoundedBuffer(int capacity) {        
    this.buf = (V[]) new Object[capacity];
        count = 0;
    }    
    protected synchronized final void doPut(V v) {
        buf[tail] = v;        if(++tail == buf.length)
            tail = 0;
        ++count;
    }    
    protected synchronized final V doTake() {
        V v = buf[head];
        buf[head] = null;        
        if(++head == buf.length)
        head = 0;
        --count;        
        return v;
    }    
    public synchronized final boolean isFull() {        
        return count == buf.length;
    }    
    public synchronized final boolean isEmpty() {        
        return count == 0;
    }
}

로그인 후 복사

제한된 캐시의 첫 번째 구현은 put 및 take 메서드를 모두 동기화하고 먼저 확인한 다음 실행하며, 실패하면 예외를 발생시킵니다.

public class GrumpyBoundedBuffer<V> extends BaseBoundedBuffer{

    protected GrumpyBoundedBuffer(int capacity) {        
        super(capacity);
    }    
    public synchronized void put(V v) throws BufferFullException {        
        if(isFull()) {            
            throw new BufferFullException();
       }
        doPut(v);
    }    
    public synchronized V take() throws BufferFullException {        
        if(isEmpty())            
            throw new BufferFullException();        
            return (V) doTake();
    }
}

로그인 후 복사

위에 표시된 것처럼 전제 조건이 충족되지 않으면 예외가 직접 발생합니다. 여기서 소위 예외는 캐시가 가득 찼거나 비어 있는 것을 의미합니다. 사실, 이 예외는 프로그램이 잘못되었다는 것을 의미하지 않습니다. 예를 들어 빨간불이 보인다고 신호등이 비정상이라는 의미는 아니지만, 초록불이 길을 건너갈 때까지 기다리는 것입니다. 따라서 이것이 의미하는 바는 호출자가 예외를 포착하고 각 캐시 작업을 다시 시도해야 한다는 것입니다.

다음 클라이언트 호출 코드를 직접 살펴보겠습니다.

private static GrumpyBoundedBuffer gbb = new GrumpyBoundedBuffer(5);
...while(true) {    try {
        V item = gbb.take();        
        break;
    } catch(BufferEmptyException e) {
        Thread.sleep(500);
    }
}

로그인 후 복사

직접 말하면 전제 조건이 충족되지 않으면 조건이 충족될 때까지 다시 시도해야 차단 효과를 얻을 수 있을 것으로 보입니다. 하지만 이 경우에는 호출자가 전제 조건의 실패를 스스로 처리해야 하며, CPU는 항상 점유되어 있습니다. 여기서 문제는 호출자가 이 대기열을 사용하는 것이 매우 번거롭다는 것입니다!

두 번째 방법인 SleepyBoundedBuffer는 폴링과 절전을 통해 간단한 차단 재시도 메커니즘을 구현하므로 호출자가 재시도 메커니즘을 제거하고 캐시 사용을 단순화할 수 있습니다. 아래 코드 목록을 살펴보세요.

public class SleepyBoundedBuffer<V> extends BaseBoundedBuffer{

    protected SleepyBoundedBuffer(int capacity) {        
        super(capacity);        
        // TODO Auto-generated constructor stub
    }    
    public void put(V v) throws InterruptedException {        
        while(true) {            
            synchronized(this) {                
                if(!isFull()) {
                    doPut(v);                    
                    return;
                }
            }
            Thread.sleep(200);
        }
    }    
    public V take() throws InterruptedException{        
        while(true) {            
            synchronized(this) {                
            if(!isEmpty()) {                    
            return (V) doTake();
                }
            }
            Thread.sleep(200);
        }
    }
}

로그인 후 복사

호출자의 관점에서 볼 때 이 접근 방식은 매우 효과적입니다. 작업이 전제 조건을 충족하면 즉시 실행되고, 그렇지 않으면 차단됩니다. 호출자는 실패 및 재시도를 처리할 필요가 없지만 호출자는 여전히 InterruptedException을 처리해야 합니다. 대부분의 잘 작동하는 차단 라이브러리 메서드와 마찬가지로 SleepyBoundedBuffer는 인터럽트를 통한 취소를 지원합니다.

SleepyBoundedBuffer의 문제점은 수면 시간 설정이 얼마나 오랫동안 합리적인가요? 최적의 성능을 어떻게 달성할 수 있습니까? 아래 그림과 같이 스레드 B는 조건을 true로 설정했지만, 이때 A는 여전히 Sleep 상태이고, 이 Sleep이 성능의 병목 현상이 됩니다.

그렇다면, 조건이 true일 때 스레드가 즉시 깨어나서 실행될 수 있는 방법이 있을까요?
생각해보면 다음 글에서 설명하도록 할게요!

위 내용은 JAVA 개발 시 실제 상태 의존성 관리를 위한 블로킹 큐 구현의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!