Executors 를 사용 하여 스 레 드 탱크 를 직접 만 들 지 마 십시오.매우 안전 하지 않 습 니 다.아 리 코드 규범 은 이렇게 스 레 드 탱크 를 만 들 수 없다 고 명확 하 게 규정 하고 있 습 니 다.안전 하고 신뢰 할 수 있 는 스 레 드 탱크 를 어떻게 정확하게 만 들 고 스 레 드 탱크 는 도구 류 를 보조 적 으로 만 듭 니까?

본인 은 신인,기술 소 백 하나 입 니 다.다음 묘사 가 잘못된 점 이 있다 면 비판 을 환영 합 니 다.바람 직 하 다 고 생각 되면,리 트 윗 할 때'좋아요'눌 러 주세요~
목차
문제.
해결 방안:
포인트 1:스 레 드 탱크 크기
중점 2:적당 한 차단 대기 열
무한 대열
유 계 대열
중점 3:명확 한 거부 전략
문제.
먼저,에서 명확 하 게 지적 했다.
[강제]스 레 드 탱크 는 Executors 를 사용 하여 만 드 는 것 을 허용 하지 않 고 Thread PoolExecutor 방식 을 통 해 작성 한 학생 들 로 하여 금 스 레 드 탱크 의 운행 규칙 을 더욱 명확 하 게 하고 자원 이 소 모 될 위험 을 피한다.
여기 서 원 리 를 말 해 보 세 요.왜 이렇게 만 들 수 없 습 니까?
먼저 new Fixed ThreadPool 과 new Single ThreadExecutor 두 가 지 를 말씀 드 리 겠 습 니 다.
이 두 개의 스 레 드 를 저장 하 는 대기 열 은 무한 합 니 다.이 영향 은 극단 적 인 상황 에서 스 레 드 가 가득 차 서 계속 들 어 오 라 고 요청 하면 대기 열 에 계속 쌓 일 수 있 습 니 다.이런 상황 은 쉽게 oom 을 만 들 수 있 기 때문에 이런 것 은 매우 안전 하지 않 습 니 다.pass 떨 어 집 니 다!
그리고 new Cached ThreadPool 과 new Scheduled ThreadPool 두 개.
이 두 스 레 드 탱크 의 수량 은 Integer.MAX 입 니 다.VALUE,매번 하나의 임무 가 올 때마다 밑바닥 을 통 해 볼 수 있 습 니 다.new 는 하나의 스 레 드 를 실행 하고 재 활용 하지 않 으 며 자원 을 매우 낭비 합 니 다.이것 은 자신 이 매번 new 스 레 드 에 갈 때마다 차이 가 없습니다.만 든 스 레 드 가 너무 많 으 면 OOM 이 되 기 때문에 이 두 가지 도 pass 가 떨 어 집 니 다.
해결 방안:
여기 서 이론 을 장황 하 게 말 하지 않 고 관건 적 인 점 을 직접 말 합 니 다.
포인트 1:스 레 드 탱크 크기
스 레 드 탱크 는 두 개의 스 레 드 수 를 설정 하고 하 나 는 핵심 탱크 스 레 드 수 이 며 하 나 는 최대 스 레 드 수 입 니 다.
만 든 스 레 드 수가 core PoolSize 와 같 을 때 설정 한 차단 대기 열 에 가입 합 니 다.대기 열 이 가득 찼 을 때 스 레 드 풀 의 수량 이 maximumPoolSize 와 같 을 때 까지 스 레 드 를 만 들 고 작업 을 수행 합 니 다.
따라서 스 레 드 탱크 의 크기 는 매우 중요 합 니 다.이것 은 당신 의 차단 대기 열 이 사용 가능 한 지,최대 스 레 드 탱크 가 사용 가능 한 지,스 레 드 탱크 를 자동 으로 확장 할 수 있 는 지,동적 조절 등 기능 이 효과 가 있 는 지,안전 한 지 등에 달 려 있 습 니 다.
중점 2:적당 한 차단 대기 열
차단 대기 열 은 모두 7 개,
3 개 는 경계 가 있 는 차단 대기 열,Array BlockingQueue,LinkedBlockingQueue,LinkedBlockingDeque 입 니 다.
3 개 는 무한 한 차단 대기 열,링크 드 Transfer Queue,Delay Queue,Priority BlockingQueue 입 니 다.
비교적 특수 한 요 소 를 저장 하지 않 는 대기 열,SynchronousQueue
무한 대열
대기 열 크기 는 제한 이 없습니다.항상 사용 되 는 링크 드 BlockingQueue 입 니 다.이 대기 열 을 차단 대기 열 로 사용 할 때 특히 조심해 야 합 니 다.작업 시간 이 오래 걸 릴 때 대량의 새로운 작업 이 대기 열 에 쌓 여 결국 OOM 을 초래 할 수 있 습 니 다.코드 를 읽 어 보 니 Executors.new Fixed ThreadPool 은 링크 드 BlockingQueue 를 사 용 했 고 건물 주가 밟 은 것 은 바로 이 구 덩이 였 습 니 다.QPS 가 높 고 데 이 터 를 많이 보 내 며 대량의 작업 이 이 무한 링크 드 BlockingQueue 에 추가 되 어 cpu 와 메모리 가 급증 하여 서버 가 끊 겼 습 니 다.
유 계 대열
자주 사용 되 는 두 가지 유형 이 있 는데 하 나 는 FIFO 원칙 을 따 르 는 대기 열,예 를 들 어 Array BlockingQueue 이 고 다른 하 나 는 Priority BlockingQueue 와 같은 우선 순위 대기 열 입 니 다.Priority BlockingQueue 의 우선 순 위 는 작업 의 Comparator 에 의 해 결 정 됩 니 다. 
경계 대기 열 을 사용 할 때 대기 열 크기 는 스 레 드 탱크 크기 와 서로 어 울 려 야 합 니 다.스 레 드 탱크 가 비교적 작 을 때 메모리 소 모 를 줄 이 고 cpu 사용률 과 문맥 전환 을 낮 출 수 있 으 나 시스템 스루풋 을 제한 할 수 있 습 니 다.
따라서 특수 요 소 를 고려 하지 않 으 면 정상 적 인 상황 에서 우 리 는 경계 대기 열 을 선택해 야 스 레 드 탱크 를 안전 하 게 만 들 수 있다.동시에 경계 대기 열 이 있어 야 다음 중점 을 발효 시 킬 수 있 습 니 다!
중점 3:명확 한 거부 전략
모두 5 중 거부 전략 이 있 습 니 다.
Thread PoolExecutor.AbortPolicy:작업 을 버 리 고 Rejected Execution Exception 이상 을 던 집 니 다.(묵인
 
ThreadPoolExecutor.DiscardPolicy  ：임 무 를 버 리 고도 이상 을 던 지지 않 는 다.
 
 
Thread PoolExecutor.DiscardOldestPolicy:대기 열 맨 앞 에 있 는 작업 을 버 리 고 다시 작업 을 시도 합 니 다(이 과정 을 반복 합 니 다)
 
 
Thread PoolExecutor.CallerRunsPolicy:이 작업 을 호출 스 레 드 로 처리 합 니 다.
마지막 으로 인 터 페 이 스 를 실현 한 다음 에 사용자 정의 거부 전략 을 실현 하 는 것 이다.이런 방법 은 자세히 말 하지 않 고 위의 몇 가지 가 어떻게 실현 되 는 지 보고 모방 하면 된다.
기본적으로 이상 을 던 집 니 다.버 릴 임 무 를 처리 하지 않 으 려 면 두 번 째 를 선택 할 수 있 습 니 다.임 무 를 버 리 고 이상 을 던 지지 않 습 니 다.임무 가 중요 하 다 면 기본 값 을 선택 하고 이상 을 포착 할 수 있 으 며,이상 중 에는 임 무 를 스스로 저장 하거나 미리 경고 하 는 것 도 가능 하 다.다 버 리 려 면 세 번 째 버 리 는 방식 도 선택 할 수 있 고 처음에 들 어 온 것 을 버 리 는 것 도 비교적 적다.그리고 네 번 째 는 작업 을 만 드 는 이 스 레 드 에서 이 일 을 처리 합 니 다.그러면 시스템 의 스루풋 을 크게 낮 출 수 있 습 니 다.특별한 상황 이 아니라면 보통 두 번 째 스 레 드 를 선택 하면 ok 입 니 다.
안전 하고 빠 르 고 편리 하 게 스 레 드 탱크 를 만 드 는 보조 도구 류 입 니 다.만약 에 완선 하지 않 은 부분 이 있 으 면 댓 글 에 따 르 면 저 는 보완 하려 고 노력 하 겠 습 니 다!이 도구 류 에는 세 가지 기본 적 인 생 성 방식 이 있 습 니 다.핵심 스 레 드 탱크 크기 만 입력 하면 됩 니 다.세 가지 기본 적 인 것 은 가득 찬 후에 버 리 는 이상 입 니 다.가득 찬 후에 버 리 지 않 고 이상 을 버 리 지 않 습 니 다.가득 찬 후에 가장 앞의 재 시도 삽입 을 버 리 고 사용자 정의 생 성 방식 도 있 습 니 다.고도 로 사용자 정의 되 고 완전히 자체 적 으로 디자인 합 니 다.그러나 필요 한 매개 변 수 는 모두 준비 되 어 있 으 며 선택 만 하면 됩 니 다.바보 식 생 성,안전 하고 편리 하 며 모든 매개 변 수 를 호출 할 때 만 들 고 넣 습 니 다.자원 을 낭비 하 는 구체 적 인 내용 을 미리 만 들 지 않 습 니 다.원본 코드 를 읽 으 십시오.주석 은 전면적 입 니 다.주석 과 이름 에 따라 무슨 뜻 인지 알 수 있 습 니 다.어 지 러 운 코드 가 있 으 면 UTF-8 로 인 코딩 을 다시 하 십시오.
아래 는 보조 링크 를 무료 로 다운로드 해 드 립 니 다.