그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Concurrency
Concurrency

경쟁 상태를 해결하려면 왜 원자성과 가시성이 함께 필요하나요?

실무5/5
설계4/5
인간4/5
기초4/5

면접관의 질문 의도

원자성과 가시성을 단어로만 외웠는지, 두 결함이 *각각 어떻게 다른 버그로 드러나는지*와 어떤 동기화 도구가 어디까지 책임지는지를 구분할 수 있는지를 가른다.

큐레이션 답변

학습 자료

경쟁 상태는 여러 스레드가 공유 자원을 동시에 갱신할 때 실행 순서에 따라 결과가 달라지는 현상이다. 원인은 두 갈래로 쪼개진다 — i++처럼 읽기·수정·쓰기로 나뉘는 연산이 중간에 끼어드는 원자성 문제와, 한 스레드의 변경이 CPU 캐시에 머물러 다른 스레드가 보지 못하는 가시성 문제다. 둘 중 하나만 잡으면 같은 버그가 모양만 바꿔 다시 나타난다.

좋은 답변 구조

  1. 01경쟁 상태가 왜 발생하는지 원자성·가시성 두 축으로 나눠 정의한다
  2. 02각 축이 깨졌을 때 드러나는 실패 시나리오를 코드 단위로 보여준다
  3. 03`synchronized`·`Atomic`·`volatile`이 각각 두 축 중 무엇을 책임지는지 구분한다
  4. 04도구 선택과 락 범위 설정에서 주의할 점까지 짚는다

자주 실수하는 포인트

`volatile`이 원자성도 보장한다고 착각해 카운터 변수에 그대로 쓴다
`i++`을 한 번에 끝나는 원자 연산으로 본다
락 범위를 한 메서드 전체로 잡아 처리량을 깎아먹는다

실무 맥락

  • 다중 스레드가 같은 재고·잔액 값을 갱신하는 결제·재고 처리 환경
  • 배치 워커가 공유 큐·캐시를 동시에 읽고 쓰는 처리 파이프라인
  • 트래픽이 늘면서 락 경합으로 응답 시간이 들쭉날쭉해지는 서비스

본인 경험에 녹이는 힌트

카운터나 재고가 가끔 어긋나는 버그를 만나 원자성 문제로 좁혀낸 경험이 있다면 진단 과정을 들고 갈 수 있다

`synchronized` 대신 `AtomicInteger`나 `LongAdder`로 바꿔 처리량을 끌어올린 경험이 있다면 선택 기준과 함께 말할 수 있다

jcstress나 부하 테스트로 동시성 결함을 재현해본 경험이 있다면 검증 방식과 한계를 함께 설명할 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1`volatile`이 보장하는 것과 보장하지 않는 것은 무엇인가요
Q2CAS 기반 Atomic 클래스가 경합이 심해질수록 비용이 어떻게 늘어나나요
Q3락 경합으로 처리량이 막힐 때 동기화 전략을 어떻게 바꾸나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문