이벤트 처리에서 함수는 값을 콜렉션에 넣고 다른 하나는 동일한 콜렉션에서 제거합니다. 항목은 원본 (소켓)에서받은 순서대로 컬렉션 내부에 배치하고 동일한 방식으로 읽어야합니다. 그렇지 않으면 결과가 변경됩니다.모든 컬렉션 또는 데이터 구조가 Java에서 블로킹되지 않습니다.
대기열은 대부분의 사람이 추천하는 컬렉션이지만 항목이 추가 될 때 대기열이 차단되므로 추가가 완료 될 때까지 기다려야 비효율적이며 작업 대기 시간이 증가합니다 .
예를 들어, 한 스레드가 큐에서 읽고 다른 스레드가 같은 큐에 씁니다. 하나의 작업은 잠금을 해제 할 때까지 대기열에서 한 번에 하나씩 수행됩니다. 이것을 피하는 데이터 구조가 있습니까?
ConcurrentLinkedQueue은 예제 중 하나입니다. java.util.concurrent에서 다른 클래스를 참조하십시오.
특정 사례에 대해 더 많은 타사 라이브러리가 있습니다 (예 : LMAX Disruptor
사실상 LinkedBlockingQueue은 걸리는 항목이있을 때까지 대기하는 블로킹 put 및 take 메소드 또는 다른 크기의 제한이있을 경우 다른 항목을 삽입 할 공간이 있기 때문에 많은 경우에 사용하기 가장 쉽습니다. 용량이 활성화되었습니다. 용량 설정은 선택 사항이며 하나도 없으면 대기열이 계속 확장 될 수 있습니다.
반면에 ArrayBlockingQueue은 가장 효율적이고 아름답습니다. 내부적으로 링 버퍼를 사용하므로 고정 된 용량을 가져야합니다. 그것은 LinkedBlockingQueue보다 훨씬 빠르지 만, 당신은 방해물로 얻을 수있는 최대 처리량과는 거리가 멀다.
두 경우 모두, 블로킹은 순전히 선택 사항이다. 모든 동시 대기 행렬의 비 차단 API도 지원됩니다. 블로킹 및 비 블로킹 API는 혼합 될 수 있습니다.
많은 경우 대기열이 병목 현상이 아니며 실제로는 방해물을 사용하는 것이 현명한 방법입니다. 큐가 아니라 링 버퍼가 서로 다른 역할을 가진 참여하는 스레드 (즉, 전형적으로 하나의 생산자, 작업자 및 하나의 소비자) 사이에서 공유된다. 설정하는 데 약간 번거롭지 만 값 비싼 변수를 필요로하지 않지만 기계에 의존하는 읽기 및 쓰기를 직렬화하는 미묘한 방법에 의존하기 때문에 현대 하드웨어에서 초당 약 1 억 트랜잭션의 속도를 낼 수 있습니다 (기본적으로 부품을 작성해야합니다. :))
그것은 스트림 처리에 바람직하지 못하다. 우리는 여러 소비자와 생산자, 1 명의 생산자와 1 명의 소비자를 사용하지 않고 있으며, 막히면 시간이 지남에 따라 처리에 도입하는 데 걸리는 시간이 늘어납니다. – user64287
뭐라 구요? 귀하의 문장을 완전히 분석 할 수 없었습니다 ... – yeoman
블로킹은 여러 생산자와 소비자에 관한 것이 아니라, 투표/수면/시간 낭비 할 필요가 없으므로 소비자 측의 블로킹 take() 사용은 실용적입니다. 또는 큐에서 Object.wait을 수동으로 호출하고 생성자에게 Object.notify를 통해 사용자에게 알리도록하십시오. – yeoman
'Queue'는 콜렉션이 아니며 여러 구현이있는 인터페이스입니다. 당신에게 맞는 것을 골라라. – EJP
제 의도는 콜렉션 프레임 워크의 구현이 콜렉션을 가져오고 넣는 기능을 가지고 사용할 수 있는지 여부를 묻는 것입니다. – user64287
그 질문은 Queue를 구현하는 모든 컬렉션의 Javadoc을 찾아 봄으로써 답을 얻습니다. 'Queue' 인터페이스에 대한 일련의 잘못된 문장을 작성하는 것은 아닙니다. – EJP