유튜브블로그Top 10
내 프로필

데브허브 안내
소개업데이트 소식

데브허브 커뮤니티

Why Haven’t They Fixed This? by Maurice Naftalin, Stuart Marks

Devoxx

2025. 10. 7.

0

#devops
#backend
  • Java 개발자들이 흔히 겪는 Concurrent Modification Exception(CME)은 컬렉션 반복 중 발생하는 고통스러운 문제로, 절반 이상의 개발자가 경험했을 정도로 보편적입니다. 💥
  • CME는 이터레이터가 컬렉션을 순회하는 동안, 해당 컬렉션이 이터레이터가 아닌 다른 경로(예: 직접 remove() 호출)로 변경될 때 발생합니다. 이는 'fail-fast' 원칙에 따라 잠재적 충돌을 즉시 알리는 방식입니다. 🚧
  • List에서 인덱스를 사용하여 요소를 제거하고 인덱스를 조정하는 방식은 특정 상황에서 작동할 수 있지만, Set이나 Map과 같은 다른 컬렉션 타입에는 적용할 수 없어 일반적인 해결책이 될 수 없습니다. 🔢
  • 컬렉션 요소를 제거할 때는 반드시 컬렉션의 remove() 메서드가 아닌, 이터레이터의 remove() 메서드를 사용해야 합니다. 이는 이터레이터가 컬렉션 변경 사항을 인지하고 처리하도록 합니다. ✅
  • Java 컬렉션 프레임워크는 여러 개의 독립적인 읽기 전용 이터레이터를 허용하며, 애플리케이션이 이터레이션을 중간에 쉽게 중단(abandon)할 수 있도록 설계되었습니다. 🚶‍♀️
  • CME를 근본적으로 해결하려면 컬렉션이 모든 활성 이터레이터를 추적하고, 컬렉션 변경 시 이터레이터들을 업데이트해야 합니다. 이는 상당한 설계 및 구현 복잡성을 야기합니다. 🧠
  • 활성 이터레이터를 추적하려면 컬렉션 내부에 추가적인 자료구조가 필요하며, 가비지 컬렉터(GC)의 약한 참조(Weak Reference)를 활용하여 사용되지 않는 이터레이터를 정리해야 합니다. 이 과정은 상당한 연산 및 메모리 오버헤드를 발생시킵니다. 💰
  • 현재의 'fail-fast' 이터레이터 디자인은 구현의 단순성, 낮은 오버헤드, 그리고 잠재적 문제에 대한 빠른 경고라는 장점을 가지며, 이는 복잡한 추적 및 업데이트 메커니즘의 비용과 맞바꾼 결과입니다. ⚖️

Recommanded Videos