자바 다 중 스 레 드 병행 제어 프레임 워 크 실현

자바 는 언어 수준의 스 레 드 지원 을 제공 하기 때문에 자바 에서 다 중 스 레 드 를 사용 하 는 것 은 C,C++에 비해 더욱 간단 하고 편리 하지만 본 고 는 자바 에서 다 중 스 레 드 를 사용 하여 웹 서비스,Number crunching 또는 I/O processing 과 같은 문 제 를 해결 하 는 방법 을 소개 하 는 것 이 아니다.본 논문 에서 우 리 는 자바 다 중 스 레 드 의 운행 구 조 를 어떻게 실현 하 는 지,그리고 우리 가 스 레 드 의 병행 동기 화 와 순 서 를 어떻게 제어 하 는 지 토론 할 것 이다.

당면 한 문제
그림 1.스 레 드 필드
이 그림 의 노드 는 single Thread 를 대표 하고 실행 절 차 를 대표 합 니 다.
전체 그림 은 ROOT 스 레 드 가 실 행 된 후 T1 스 레 드 를 실행 하고 T1 이 실 행 된 후 동시 다발 적 으로 실행 되 는 T2 와 T3 를 의미한다.T2 와 T3 가 T4 를 가리 키 는 두 변 은 T4 가 T2 와 T3 가 모두 실 행 된 후에 야 실 행 될 수 있다 는 것 을 나타 낸다.나머지 절 차 는 END 가 전체 과정 으로 끝 날 때 까지 이런 식 으로 유추 된다.물론 이것 은 간단 한 설명도 일 뿐 직면 할 수 있 는 스 레 드 장면 에 수백 개의 스 레 드 가 있 을 것 이다.그리고 이 전체 장면 은 입구 점 하나 와 출구 점 하나 밖 에 없다 는 것 을 관찰 할 수 있다.이것 은 무엇 을 의미 하 는 것 입 니까?다음 글 에서 설명해 드 리 겠 습 니 다.
그 중에서 자바 스 레 드 의 동기 화 상호 배척 체제 와 관련된다.예 를 들 어 T1 을 T2 와 T3 이전에 어떻게 실행 시 키 고 T2 와 T3 를 모두 실행 한 후에 T4 스 레 드 를 열 수 있 습 니까?
모델 설명
어떻게 그림 1 에서 보 여 준 장면 을 묘사 합 니까?XML 형식 으로 우리 의 모델 을 묘사 할 수 있 습 니 다.나 는 스 레 드 를 표시 하기 위해"Thread"element 를 정의 합 니 다.

<ThreadList>
<Thread ID = "thread-id" PRETHREAD = "prethread1, prethread2…"></Thread>
<Thread ID = "thread-id" PRETHREAD = "prethread3, prethread4…"></Thread>
</ThreadList>

그 중에서 ID 는 스 레 드 의 유일한 식별 자 이 고 PRETHREAD 는 바로 이 스 레 드 의 직접 선 결 스 레 드 ID 이 며 모든 스 레 드 ID 사 이 를 쉼표 로 분리 합 니 다.
Thread 이 element 에 서 는 이 스 레 드 에서 작업 을 수행 하고 자 하 는 구체 적 인 정 보 를 추가 할 수 있 습 니 다.
실제 모델 의 묘 사 는 문 제 를 해결 하 는 매우 중요 한 부분 으로 전체 스 레 드 장면 은 일치 하 는 형식 으로 묘사 할 수 있 으 며 자바 다 중 스 레 드 병행 제어 프레임 엔진 의 입력 으로 할 수 있다.즉,스 레 드 가 실행 되 는 모드 를 XML 로 설명 하 는 것 입 니 다.XML 프로필 만 바 꾸 면 전체 스 레 드 가 실행 되 는 모드 를 변경 할 수 있 고 소스 코드 를 바 꾸 지 않 아 도 됩 니 다.
두 가지 실현 메커니즘
자바 다 중 스 레 드 의 운영 프레임 워 크 에 있어 서 우 리 는'외'와'내'의 두 가지 모델 로 이 루어 질 것 이다.
"외"-메 인 스 레 드 폴 링
그림 2.정적 도표
Thread 는 작업 스 레 드 입 니 다.ThreadEntry 는 Thread 의 포장 류 입 니 다.prerequisite 는 HashMap 입 니 다.Thread 의 선 결 스 레 드 상 태 를 포함 하고 있 습 니 다.그림 1 에서 보 듯 이 T4 의 선 결 스 레 드 는 T2 와 T3 이 고 prerequisite 에는 T2 와 T3 의 상태 가 포함 되 어 있 습 니 다.TestScenario 의 threadEntry List 에는 모든 ThreadEntry 가 포함 되 어 있 습 니 다.
그림 3.스 레 드 실행 장면
TestScenario 는 메 인 스 레 드 로 서"외부"모니터링 자로 서 threadEntry List 의 모든 ThreadEntry 상 태 를 계속 문의 합 니 다.ThreadEntry 가 isReady 의 조 회 를 받 은 후에 자신의 prerequisite 를 조회 합 니 다.그 중의 모든 선 결 스 레 드 상태 가"정상 적 으로 끝 날 때"이면 ready 로 돌아 갑 니 다.그러면 TestScenario 는 ThreadEntry 의 startThread()방법 으로 이 ThreadEntry 실행 스 레 드 를 권한 을 부여 하고 Thread 는 run()방법 으로 스 레 드 를 진정 으로 실행 합 니 다.그리고 정상적으로 실 행 된 후에 setPreRequisteState()방법 을 사용 하여 전체 Scenario 를 업데이트 합 니 다.threadEntry List 의 모든 ThreadEntry 에 prerequisite 에 이 Thread 의 상태 정 보 를'정상 종료'로 포함 합 니 다.
그림 4.상태 변경 과정
그림 1 에서 보 듯 이 T4 의 선 결 스 레 드 는 T2 와 T3,T2 와 T3 를 병행 한다.그림 4 에서 보 듯 이 T2 가 먼저 실행 되 었 다 고 가정 하면 setPreRequisteState()방법 으로 전체 Scenario 를 업데이트 합 니 다.threadEntry List 에 있 는 모든 ThreadEntry 에 있 는 prerequisite 에는 이 T2 의 상태 정보 가'정상 적 인 종료'로 포함 되 어 있 습 니 다.이때 T4 의 prerequisite 중 T2 의 상 태 는'정상 종료'였 으 나 T3 가 아직 실행 이 끝나 지 않 아'미 완료'상태 다.따라서 T4 의 isReady 조 회 는 false 로 되 돌아 가 고 T4 는 실행 되 지 않 습 니 다.T3 실행 이 끝나 고 상태 가'정상 종료'로 업 데 이 트 된 후에 야 T4 의 상태 가 ready 이 고 T4 가 실 행 될 수 있다.
나머지 노드 도 이런 식 으로 추정 된다.정상적으로 실 행 될 때 전체 시나리오 에서 이 라인 이 정상적으로 끝 난 정 보 를 방송 하고 메 인 라인 에서 각 ThreadEntry 의 상 태 를 끊임없이 돌아 가면 서 각 라인 을 연다.
이것 은 바로 주 제어 스 레 드 폴 링 상태 표 방식 으로 자바 다 중 스 레 드 운행 프레임 워 크 를 제어 하 는 실현 방식 중 하나 이다.
장점:개념 구조 가 뚜렷 하고 간단 하 다.자바 의 잠 금 체 제 를 사용 하지 않 고 잠 금 이 생 길 확률 을 감소 합 니 다.이상 이 발생 하여 일부 스 레 드 가 정상적으로 실행 되 지 않 을 때 걸 려 있 는 스 레 드 가 발생 하지 않 습 니 다.
단점:메 인 스 레 드 폴 링 체 제 를 사용 하여 CPU 시간 을 소모 합 니 다.그림 의 노드 가 너무 많은(n>???스 레 드 단일 스 레 드 실행 시간 이 비교적 짧 을 때 t"내"-wait&notify
'외'-메 인 스 레 드 폴 링 체제 에 비해'내'는 자체 통제 체인 트리거 체 제 를 사용한다.
그림 5.잠 금 메커니즘 의 정적 도표
Thread 의 lock 은 현재 Thread 의 lock 입 니 다.lockList 는 HashMap 입 니 다.후계 스 레 드 를 가 진 lock 의 참조 입 니 다.getLock 과 setLock 은 lockList 의 Lock 을 조작 할 수 있 습 니 다.그 중 중요 한 멤버 는 wait ForCount 로 인용 계수 입 니 다.현재 스 레 드 가 기다 리 고 있 는 선 결 스 레 드 의 개 수 를 나타 낸다.예 를 들 어 그림 1 에서 보 여 준 T4 는 초기 상황 에서 그 가 기다 리 고 있 는 선 결 스 레 드 가 T2 와 T3 이면 wait ForCount 는 2 와 같다.
그림 6.잠 금 메커니즘 실행 순서 도
전체 과정 이 실 행 될 때 우 리 는 모든 스 레 드 start 를 시작 합 니 다.그러나 모든 스 레 드 가 가지 고 있 는 lock 은 wait 상태 에 있 고 스 레 드 는 waiting 상태 에 있 습 니 다.이 때,루트 thread 가 가지 고 있 는 자신의 lock notify 를 루트 thread 가 실 행 됩 니 다.루트 의 run 방법 이 실 행 된 후에후속 스 레 드 의 wait ForCount 를 검사 하고 값 을 1 로 줄 입 니 다.그리고 waitForCount 를 다시 검사 합 니 다.waitForCount 가 0 이면 이 후속 스 레 드 의 모든 선 결 스 레 드 가 실행 되 었 음 을 표시 합 니 다.이때 notify 이 스 레 드 의 lock 은 이 후속 스 레 드 가 waiting 상태 에서 running 상태 로 전환 할 수 있 습 니 다.그리고 이 과정 이 연쇄 적 으로 진행 되면 전체 과정 이 실 행 될 것 이다.
우 리 는 여전히 T2,T3,T4 를 예 로 들 어 initThreadLock 과정 을 진행 할 때 T4 는 두 개의 직접 선 결 라인 T2 와 T3 가 있 기 때문에 T4 의 wait ForCount 는 2 와 같다 는 것 을 알 수 있다.우 리 는 T3 가 먼저 실행 되 었 다 고 가정 합 니 다.T2 는 여전히 running 상태 에 있 습 니 다.이때 그 는 먼저 모든 직접 후계 스 레 드 를 옮 겨 다 니 고 그들의 wait ForCount 를 1 로 줄 입 니 다.이때 그 는 하나의 직접 후계 스 레 드 T4 만 있 습 니 다.그래서 T4 의 wait ForCount 에서 1 을 빼 고 0 과 다 르 지 않 습 니 다.이때 T4 의 lock notify,T4 를 계속 기다 리 지 않 습 니 다.T2 가 실 행 된 후에 그 는 T3 와 같은 절 차 를 수행 할 것 이다.이때 T4 의 wait ForCount 는 0 이 고 T2 는 notify T4 의 lock 이 므 로 T4 는 waiting 상태 에서 running 상태 로 전환 된다.다른 노드 도 비슷 한 상황 이다.
물론 우 리 는 전체 과정의 정 보 를 다른 전체 대상 에 두 고 모든 스 레 드 는 이 전체 대상 을 찾 아 각자 가 필요 로 하 는 정 보 를 얻 을 수 있 습 니 다.이런 분포 식 저장 방식 을 사용 하 는 것 이 아 닙 니 다.
장점:wait¬ify 메커니즘 을 사용 하고 폴 링 메커니즘 을 사용 하지 않 으 며 CPU 자원 을 낭비 하지 않 습 니 다.집행 효율 이 비교적 높다.또한'외'-메 인 스 레 드 폴 링 의 체제 에 비해 실시 성 이 더욱 좋다.
단점:자바 스 레 드 Object 의 잠 금 체 제 를 사용 하여 실현 하기 가 비교적 복잡 하 다.또한,일부 스 레 드 가 이상 하면 모든 후속 스 레 드 가 걸 려 서 전체 시나리오 의 운행 에 실패 할 수 있 습 니 다.이런 상황 의 발생 을 방지 하기 위해 서 우 리 는 반드시 스 레 드 모니터링 체 제 를 구축 하여 정상 적 인 운행 을 확보 해 야 한다.
뻗다
아래 의 그림 에서 표현 하고 자 하 는 것 은 이러한 순환 교체 의 개념 이다.예 를 들 어 그림 1 에서 보 여 준 것 처럼 T1 이 노드 는 하나의 스 레 드 를 나타 낸다.지금 은 스 레 드 라 는 개념 을 잊 고 T1 을 하나의 과정 으로 추상 화하 고 은하계 라 고 상상 하 며 T1 에 깊이 들 어가 면 많은 서브 과정의 집합 이기 도 한다.이런 서브 과정 간 의 관계 모델 은 그림 1 과 같이 하나의 그림 으로 표시 할 수 있다.
그림 7.소켓 과정
이것 이 어떤 구조 인지 상상 할 수 있 고 무한 한 확장 성 을 가 진 과정 구 조 를 가 집 니 다.우 리 는 각 과정 간 의 관 계 를 정의 할 수 있 습 니 다.우 리 는 과정 이 어떻게 돌아 가 는 지 에 관심 을 가 질 필요 가 없습니다.사실은 최종 노드 에 실제 작업 을 지정 할 수 있 습 니 다.예 를 들 어 파일 을 읽 거나 JCL job 를 제출 하거나 sql statement 을 실행 할 수 있 습 니 다.
사실은 특정한 옮 겨 다 니 는 규칙 에 따라 이런 포 함 된 재 귀 구 조 를 원래 의 분 층 된 그물 모양 구조 가 아니 라 평면 구조의 그림 으로 전환 시 킬 수 있다.그러나 우리 가 이렇게 하지 않 는 이 유 는 다음 과 같은 몇 가지 고려 를 바탕 으로 하 는 것 이다.
4.567917.이렇게 하면 그림 의 노드 가 너무 많 고 가장자리 가 너무 많아 서 눈 이 어지럽다
4.567917.이렇게 하지 않 는 가장 중요 한 이 유 는 모든 장면 이다.그림 7 의 T1,T13 은 상태 가 모인 단원 으로 높 은 재 활용 성과 신뢰성 을 가진다
4.567917.구 조 는 고도 로 추상 적 인 것 으로 그의 실제 집행 은 분포 식 일 수 있 고 한 단원 은 하나의 시스템 으로 다른 시스템 과 의 분계 표지 로 할 수 있다
실제로 이것 은 상태 가 모인 차원 제어 프레임 워 크 로 우 리 는 이 프레임 워 크 에 의존 하여 자주 연산 을 수행 할 수 있다.