조용한 개발 노트

2편에서 MVCC가 읽기와 쓰기의 충돌을 어떻게 줄이는지 살펴봤다.하지만 실무에서는 이런 상황을 훨씬 자주 마주친다.“읽기 쿼리는 잘 되는데, UPDATE가 갑자기 멈췄다.” “트랜잭션이 끝났는데도 락 대기가 풀리지 않는다.”이 문제의 원인은 대부분 MVCC가 해결하지 못한 영역, 즉 락(Lock)에 있다.InnoDB에서 락은 왜 필요한가MVCC가 있어도 모든 상황을 과거 버전 읽기로 해결할 수는 없다.특히 다음 상황에서는 동시 쓰기 충돌을 반드시 막아야 한다.같은 행을 동시에 UPDATE존재 여부를 전제로 한 INSERT범위 조건을 만족하는 행 수정이때 InnoDB는 과거 버전을 보여주는 대신, 락으로 질서를 강제한다.Row Lock - 가장 기본적인 락가장 직관적인 락은 Row Lock이다.특정 행 ..

1편에서 트랜잭션이 왜 본질적으로 느릴 수밖에 없는지, Undo Log와 Redo Log의 비용 관점에서 살펴봤다.이쯤에서 자연스럽게 이런 의문이 든다.“그런데 읽기 트랜잭션은 왜 락 없이도 동작할 수 있을까?”이 질문에 대한 답이 바로 MVCC(Multi-Version Concurrency Control)다.MVCC가 등장한 이유전통적인 락 기반 동시성 제어에서는 읽기와 쓰기가 서로를 쉽게 막는다.읽는 동안 쓰기가 대기한다쓰는 동안 읽기가 대기한다동시 사용자가 늘어날수록, 처리량은 급격히 떨어진다.InnoDB는 이 문제를 해결하기 위해 “락을 덜 거는 방법”이 아니라 과거 버전을 읽게 하는 방법을 선택했다.그 결과물이 MVCC다.MVCC의 핵심 아이디어MVCC의 핵심은 단순하다.“읽을 때 현재 값을 보..

volatile이 가시성을 보장하는 도구라면, synchronized와 Lock은 배타적 실행을 보장하는 도구다.멀티스레드 환경에서 “동시에 실행되면 안 되는 코드”를 어디까지, 어떻게 보호할 것인가는 동시성 설계의 핵심이다.이 글에서는 synchronized와 Lock이 무엇을 보장하고, 어디까지 책임지는지를 Java Memory Model과 공식 API 기준으로 정리한다.1. 배타성(Exclusivity)이 필요한 이유여러 스레드가 같은 데이터를 동시에 수정하면, 다음과 같은 문제가 발생한다.중간 상태가 노출된다불변식(invariant)이 깨진다연산 결과가 예측 불가능해진다이 문제를 해결하는 가장 직접적인 방법은 “한 번에 하나의 스레드만 실행하게 만드는 것” 이다.synchronized와 Lock은..