neomm

지난 포스팅에서는 응답 속도를 높이려다 메모리 단편화라는 치명적인 단점을 안고 역사 속으로 사라진 CMS GC에 대해 알아보았습니다. 구글, 넷플릭스 등 대규모 트래픽을 처리하는 글로벌 IT 기업들은 거대한 힙(Heap) 메모리를 사용하면서도 시스템이 멈추는 시간(Stop-The-World)을 예측하고 제어할 수 있는 새로운 가비지 컬렉터가 필요했습니다. 그렇게 탄생하여 Java 9부터 공식적인 디폴트(기본) GC로 채택된 것이 바로 G1 GC(Garbage First GC)입니다. … 더 읽기

지난 포스팅에서는 가비지 컬렉션(GC)의 기본 원리와, 시스템을 멈추게 하는 ‘Stop-The-World(STW)’ 현상에 대해 알아보았습니다. GC가 메모리를 청소하는 동안 애플리케이션이 멈추는 것은 불가피하지만, ‘얼마나 오래 멈출 것인가’는 어떤 GC 알고리즘을 선택하느냐에 따라 크게 달라집니다. Java는 애플리케이션의 규모와 서버의 하드웨어 환경(CPU 코어 수 등)에 맞춰 최적의 성능을 낼 수 있도록 다양한 GC 알고리즘을 제공해 왔습니다. 이번 글에서는 Java의 … 더 읽기

가비지 컬렉션(GC)의 기본 원리와 세대별(Generational) 메모리 관리 지난 포스팅에서는 객체들이 생성되고 저장되는 공간인 JVM 힙(Heap) 메모리의 세부 구조를 살펴보았습니다. C나 C++ 같은 언어에서는 개발자가 직접 메모리를 할당하고 해제해야 하지만, Java는 가비지 컬렉션(Garbage Collection, 이하 GC)이라는 훌륭한 매커니즘이 이 작업을 자동으로 수행해 줍니다. 하지만 자동이라는 말이 ‘신경 쓰지 않아도 된다’는 의미는 절대 아닙니다. 트래픽이 집중되는 엔터프라이즈 … 더 읽기

지난 포스팅에서는 JIT 컴파일러가 어떻게 Java의 실행 속도를 끌어올리는지 알아보았습니다. 코드가 빠르게 실행되는 것도 중요하지만, 엔터프라이즈 환경에서 서버가 멈추지 않고 안정적으로 돌아가기 위해서는 ‘메모리 관리’가 필수적입니다. Java 애플리케이션에서 OutOfMemoryError(OOM)가 발생하거나 원인 모를 서버 지연 현상이 나타날 때, 가장 먼저 들여다봐야 할 곳이 바로 JVM 힙(Heap) 메모리입니다. 이번 글에서는 객체들이 살아가고 소멸하는 무대인 힙 메모리의 세부 … 더 읽기

지난 포스팅에서는 JVM의 전체적인 아키텍처와 런타임 데이터 영역의 역할들을 살펴보았습니다. 이번 글에서는 그중 첫 번째 관문이자, 많은 개발자가 간과하기 쉬운 클래스로더(Class Loader)에 대해 집중적으로 파헤쳐 봅니다. Java의 가장 큰 특징 중 하나는 런타임에 클래스를 동적으로 로드한다는 점입니다. 애플리케이션이 실행될 때 모든 코드를 한 번에 메모리에 올리지 않고 필요한 순간에 로드합니다. 이 동적 로딩을 책임지는 클래스로더의 … 더 읽기

지난 글에서는 Java 애플리케이션의 성능 저하를 일으키는 3가지 주요 원인에 대해 알아보았습니다. 이러한 성능 문제를 근본적으로 해결하고 시스템을 최적화하기 위해서는 우리가 작성한 코드가 실제로 어디서, 어떻게 실행되는지 그 환경을 정확히 이해해야 합니다. 그 중심에 있는 것이 바로 JVM(Java Virtual Machine, 자바 가상 머신)입니다. “Write Once, Run Anywhere(한 번 작성하면 어디서든 실행된다)”라는 Java의 철학을 가능하게 해주는 … 더 읽기

엔터프라이즈 환경에서 Java 애플리케이션의 성능은 비즈니스의 성공과 직결되는 핵심 요소입니다. 트래픽이 몰리는 피크 타임에 서버 응답 속도가 현저히 느려지거나 원인을 알 수 없는 타임아웃(Timeout)이 발생한다면, 사용자 경험은 크게 훼손될 수밖에 없습니다. Java는 JVM(Java Virtual Machine)이라는 훌륭한 아키텍처 위에서 동작하며 가비지 컬렉션(Garbage Collection)을 통해 메모리를 자동으로 관리해 주지만, 이것이 개발자가 성능 최적화를 간과해도 된다는 의미는 아닙니다. … 더 읽기