2026
커밋하지 않은 SELECT 하나가 전 API를 멈춘 이유. MySQL 메타데이터 락
운영 데이터를 보정하다 트랜잭션을 24분간 열어뒀는데, 앞의 15분은 아무 일도 없었습니다. 서비스가 멈춘 건 그 사이 배포가 던진 ALTER TABLE 한 줄 때문이었고, 정작 InnoDB 행 락 지표는 끝까지 0이었습니다.
종료에 120초가 걸리던 이유: ScheduledThreadPoolExecutor의 대기 큐
배포 때마다 찍히는 에러 알림 한 건을 따라가다 보니, 죽어 있던 graceful shutdown 설정을 깨운 커밋과 큐에 남은 지연 작업들이 나왔습니다. JDK의 종료 정책 한 줄을 바꿔 destroy()를 120초에서 1ms로 줄인 과정을 기록했습니다.
InnoDB 락 모드. RECORD, X, GAP, REC_NOT_GAP의 관계
performance_schema.data_locks를 조회하면 LOCK_TYPE과 LOCK_MODE라는 두 컬럼이 나온다.
2025
MySQL Gap Lock 데드락. 가설 반증과 격리 수준 변경으로 해결
컨슈머들이 같은 테이블에 DELETE + INSERT를 병렬 수행하면서 REPEATABLE READ의 gap lock으로 데드락이 났습니다. 처음 세운 서브쿼리 가설은 performance_schema.data_locks 비교로 반증됐고, 진짜 원인은 격리 수준이었습니다.
런타임 필드 접근이 필요할 때, BeanWrapper를 고려해보자
문자열 키("korName")로 객체의 프로퍼티 값을 가져와야 한다면, 어떻게 하시겠어요? 리플렉션? ObjectMapper?
왜 롤백이 되었을까
로컬에서만 알림이 저장되지 않고 dev/prod는 멀쩡했습니다. 디버거로는 분명히 저장되는데 DB에는 없었고, AOP 로그를 따라가며 트랜잭션이 되감긴 지점을 좁혔습니다.
2024
커넥션 풀 고갈 문제를 Redis Atomic 연산으로 개선하기
1000명 규모 조직에서 50~100명이 동시에 이슈를 생성하는 상황을 가정하고, 목표 지표를 먼저 못 박은 뒤 부하 테스트로 검증했습니다.
스레드 풀과 Executor 프레임워크
1. 스레드 생성 비용으로 인한 성능 문제 : 스레드 생성하는 작업은 시스템 콜을 통해 처리되며, 이는 OS 커널 레벨에서 메모리 할당등이 일어나기 때문에 성능이 느립니다.
메모리 가시성과 동시성
멀티스레드 환경에서 한 스레드가 변경한 값이 다른 스레드에서 언제 보이는지 알 수 없는 문제를 메모리 가시성(memory visibility)이라 합니다.
JVM Garbage Collection (4)
Old 영역은 기본적으로 데이터가 가득 차면 GC를 실행합니다. GC 방식은 Serial GC, Parallel GC,
JVM Garbage Collection (3)
자바 가상 머신(JVM)의 메모리 관리 방식에 큰 영향을 준 중요한 개념입니다. 이 가설을 이해하면 다양한 가비지 컬렉션 알고리즘의 작동 원리를 더 잘 이해할 수 있습니다.
JVM Garbage Collection (2)
Mark and Sweep 알고리즘은 Garbage Collection의 기본 알고리즘 입니다. JVM에서 사용되는 실제 알고리즘은 훨씬 복잡하지만 Mark & Sweep 알고리즘이 기반이므로 확실히 이해해야 합니다.
JVM Garbage Collection (1)
자바프로그램이 JVM 위에서 실행하기까지 다음과 같은 과정을 거칩니다.