스레드 풀은 재사용 스레드 집합, 대기 작업 큐, 스케일링·거절 정책 세 부분으로 이루어진 관리 추상화이며, 비싼 자원을 생성·소멸의 대상이 아니라 빌리고 반납하는 대상으로 취급합니다. 스레드를 매번 만들고 없애며 적정 개수를 사람이 계속 조정하는 것은 불가능하므로, corePoolSize·maximumPoolSize·큐 용량·keepAliveTime·거절 정책을 한 번 계약으로 정해 두면 풀이 core → queue → max 순으로 확장하고 유휴 시 keepAlive로 축소합니다. 특히 큐 종류가 스케일링 성격을 좌우해서 무제한 LinkedBlockingQueue를 쓰면 maximumPoolSize가 무의미해지고, Executors 팩토리 메서드에는 이런 숨은 무제한이 있어 운영에서는 ThreadPoolExecutor를 직접 구성하고 다운스트림 커넥션 풀 상한과 정합시켜야 합니다.
"공유·가변·최소 1개의 쓰기" 세 조건이 동시에 성립할 때만 스레드 안전 문제가 생기며, 증상은 데이터 오염(갱신 유실·찢어진 상태·컬렉션 파손·dirty read), 가시성 부재(캐시·재정렬로 변경이 다른 스레드에 안 보임), 순서 재정렬(DCL 붕괴)의 세 갈래로 나타납니다. 이를 Lock으로 막으면 이번에는 경합으로 병렬성이 사라지고(암달의 법칙), 획득 순서 불일치로 데드락이 생기며, 기아·잘못된 락 객체·임계 구역 안 외부 호출 같은 새로운 문제가 따라옵니다. JMM은 synchronized·volatile·java.util.concurrent가 만드는 happens-before 관계로만 보장을 제공하므로 동기화가 하나도 없으면 아무것도 보장되지 않으며, 해결은 공유 제거 → 원자 도구 → 락 최소화 순으로 접근합니다.
Kafaka로 동일 action을 실행할때, 파티셔닝을 과도하게 나눠서 동시 실행을 하다보면, sequncail 작업이 꼬이는 경험을 할 수 있습니다. 이때, 이행했던 작업과 고민했던 작업에 대해서 작성해봤습니다.