Concurrency 35
- ParityPay로 검증하는 결제 정합성 10 - 락 lease가 트랜잭션보다 먼저 끝나면 정말 정합성이 깨지는가: SETNX 락, Watchdog, fencing token, 그리고 락 없는 구조의 실측
- Martin Kleppmann 「How to do distributed locking」 리뷰 — 효율을 위한 락과 정확성을 위한 락, fencing token이 막는 것과 못 막는 것, 그리고 lease의 시계는 누구 것인가
- ParityPay로 검증하는 결제 정합성 2 - 잠금을 필요 이상으로 오래 쥐고 있었다: 추론을 측정으로 바꾼 기록
- NIO와 이벤트 루프 - 셀렉터, 다이렉트 버퍼, Netty가 대신 해주는 일
- TMC 25 리뷰 - '주식모으기' 서비스로 살펴보는 대용량 트래픽 처리 노하우: 200만 주문을 3,000건으로 접는 풀링 주문과 그 대가
- 2026-08-30-TIL: 새 저장소 다섯 개로 시작한 한 주와 동시 정답 제출
- 순서와 격리는 같은 자원을 반대로 당긴다 - 핫 키가 워커 하나를 넘는 순간 세 설계가 갈라지는 지점
- 리액티브와 백프레셔 - WebFlux가 해결하는 것과 옮기는 것
- 가상 스레드를 켜서 37배 느려진 엔드포인트 - 핀닝과 상한 없는 admission을 재다
- SLASH 23 리뷰 - 실시간 시세 데이터 안전하고 빠르게 처리하기: Kafka 15ms 대 Redis Pub/Sub 3ms, 그리고 22,000 TPS에서 1ms를 만든 이벤트 루프 설계
- SLASH 22 리뷰 - 애플 한 주가 고객에게 전달되기까지: 분산락 위에 낙관적 락을 얹고, 타임아웃을 실패로 확정하지 않는 해외주식 원장
- 락의 종류와 대기 - row, gap, next-key, intention과 데드락 탐지
- 토스증권 공개 자료로 읽는 시세·주문 아키텍처: 무엇을 잃어도 되는지 먼저 정한다
- 뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계
- 가상 스레드의 내부 - 스케줄러와 캐리어, 핀닝, 그리고 쓰지 않아야 할 때
- 시간과 순서 - 물리 시계의 한계, 논리 시계, 하이브리드 시계
- SLASH 23 리뷰 - 은행 최초 코어뱅킹 MSA 전환기 (feat. 지금 이자 받기): 80회 DML을 50회로, MCI 대비 170배, 빅뱅 없는 전환
- 캐시 스탬피드와 single flight - 200명 중 125명이 원본까지 갔고, 예외를 삼키자 실패가 가장 빠른 요청이 됐다
- 동시성 도구의 비용 - synchronized, ReentrantLock, CAS가 경쟁에서 갈리는 지점
- 격리 수준의 이상 현상을 직접 만들기 - 같은 REPEATABLE READ에서 PostgreSQL은 중단시키고 MySQL은 조용히 덮어썼다
- 자바 메모리 모델 - happens-before, volatile, 그리고 final의 안전 공개
- 격리 수준과 이상 현상 - 표준이 정의한 것과 MySQL·PostgreSQL이 실제로 하는 것
- 대량 배치 안정성을 높이기 위한 구조 개선: Part 1 - 시스템을 압박하기 시작한 배치
- 대량 배치 안정성을 높이기 위한 구조 개선: Part 0 - 왜 이 배치는 가끔 터질까?
- 정산이 진행되는 동안 기준 데이터 수정을 막는 방법: 상태 플래그와 AOP로 만든 경량 락
- Multithreading
- 대용량 지분율 데이터 처리 성능 개선과 동시성 제어 전략
- 세마포어와 permit - 동시에 몇 개까지 들일지를 세는 도구, 그리고 벌크헤드
- thread dump 읽는 법 - 스레드 상태와 스택 프레임, 그리고 RUNNABLE이 CPU를 쓴다는 뜻이 아닌 이유
- Lock-Free와 CAS - 락 없이 공유 변수를 바꾸는 방법과 그 한계
- Spring과 JPA에서 Race Condition을 다루는 방법
- Thread Local
- Java Concurrency
- Concurrency Control
- 동기·비동기 강의 정리: 기다림과 실행 순서를 따로 보기