기술 학습과 문제 해결 기록

{ code }이미지 불러오는 중

스레드 풀은 재사용 스레드 집합, 대기 작업 큐, 스케일링·거절 정책 세 부분으로 이루어진 관리 추상화이며, 비싼 자원을 생성·소멸의 대상이 아니라 빌리고 반납하는 대상으로 취급합니다. 스레드를 매번 만들고 없애며 적정 개수를 사람이 계속 조정하는 것은 불가능하므로, corePoolSize·maximumPoolSize·큐 용량·keepAliveTime·거절 정책을 한 번 계약으로 정해 두면 풀이 core → queue → max 순으로 확장하고 유휴 시 keepAlive로 축소합니다. 특히 큐 종류가 스케일링 성격을 좌우해서 무제한 LinkedBlockingQueue를 쓰면 maximumPoolSize가 무의미해지고, Executors 팩토리 메서드에는 이런 숨은 무제한이 있어 운영에서는 ThreadPoolExecutor를 직접 구성하고 다운스트림 커넥션 풀 상한과 정합시켜야 합니다.

{ code }이미지 불러오는 중

"공유·가변·최소 1개의 쓰기" 세 조건이 동시에 성립할 때만 스레드 안전 문제가 생기며, 증상은 데이터 오염(갱신 유실·찢어진 상태·컬렉션 파손·dirty read), 가시성 부재(캐시·재정렬로 변경이 다른 스레드에 안 보임), 순서 재정렬(DCL 붕괴)의 세 갈래로 나타납니다. 이를 Lock으로 막으면 이번에는 경합으로 병렬성이 사라지고(암달의 법칙), 획득 순서 불일치로 데드락이 생기며, 기아·잘못된 락 객체·임계 구역 안 외부 호출 같은 새로운 문제가 따라옵니다. JMM은 synchronized·volatile·java.util.concurrent가 만드는 happens-before 관계로만 보장을 제공하므로 동기화가 하나도 없으면 아무것도 보장되지 않으며, 해결은 공유 제거 → 원자 도구 → 락 최소화 순으로 접근합니다.

{ code }이미지 불러오는 중

Kafaka로 동일 action을 실행할때, 파티셔닝을 과도하게 나눠서 동시 실행을 하다보면, sequncail 작업이 꼬이는 경험을 할 수 있습니다. 이때, 이행했던 작업과 고민했던 작업에 대해서 작성해봤습니다.

{ code }이미지 불러오는 중

Java 문법 01. 프로그램 구조와 실행

{ code }이미지 불러오는 중

Java 문법 02. 변수와 기본 타입, 형 변환

{ code }이미지 불러오는 중

GC(Garbage Collection)는 프로그램이 더 이상 접근할 수 없는(도달 불가능, unreachable) 객체가 점유한 힙(Heap) 메모리를 자동으로 회수하는 JVM 기능입니다. 회수 대상 판정은 참조 카운팅이 아니라 GC Root로부터의 도달 가능성(reachability)을 기준으로 하므로, 서로만 참조하는 순환 참조 덩어리도 루트에서 닿지 않으면 통째로 회수됩니다.