일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- corePoolSize
- mitmproxy
- 네트워크 디버깅
- HashMap vs ArrayMap
- APK로딩
- Service 팁
- enum performance
- ArrayMap
- 음량표준화
- Service관리
- MediaDataSource
- print callstack
- BlockingQueue Capacity
- lufs
- gitignore작성법
- RxJava Programming
- RxJava 스터디
- 오픈소스라이선스
- Intent String 변환
- convert Intent to string
- convert string to intent
- gitignore
- so파일 동적로딩
- APK 동적로딩
- Dagger2란
- callstack 출력
- Replaygain
- android enum
- android network
- java callstack
- Today
- Total
일상&개발 로그
ThreadPoolExecutor에서 corePoolSize와 queue capacity의 관계 본문
ThreadPoolExecutor는 ExecutorService를 상속받은 클래스로
Task(Runnable)를 저장하는 BlockingQueue와 이를 수행하는 ThreadPoolSize를 설정할 수 있다.
ThreadPoolExecutor 생성자에서 corePoolSize와 maximumPoolSize, BlockingQueue를 지정할 수 있는데,
여기서 지정하는 BlockingQueue의 capacity가 unbound인 경우, threadPoolSize는 corePoolSize에서 늘어나지 않는다.
구동되는 threadPool의 크기를 maximumPoolSize만큼 늘리려면 BlockingQueue의 capacitiy를 지정해 줘야한다.
주의할 점은 capacity를 지정할 경우 corePoolSize + capacity를 넘어가는 요청이 들어오게 되면 따로 Policy를 지정해주지 않으면 RejectedExecutionException이 발생하게 되므로, 잘 고려해서 설정해야 한다.
정리하자면 아래 표와 같다.
형태 |
queue예시 |
동작 |
bound |
ArrayBlockingQueue |
queue의 capacity를 넘어가는 task요청이 들어오면 maximumPoolSize까지 threadPoolSize를 늘리고, 그래도 부족하면 RejectedExecutionException이 발생한다. |
unbound |
LinkedBlockingQueue | corePoolSize를 넘어가는 task요청이 들어오면 threadPoolSize를 변경시키지 않고, 수행중인 task가 종료될 때까지 대기한다. maximumPoolSize는 의미가 없다. |
'개발 > 개발 일반' 카테고리의 다른 글
Git 최신태그와 local간의 차이점 쉽게 비교하는 방법 (0) | 2017.11.03 |
---|---|
Singleton - DCL과 Demand Holder (0) | 2017.08.07 |
OpenSource Licence 종류 (0) | 2017.06.05 |
.gitignore파일 쉽게 생성하기 (0) | 2017.02.08 |