가비지 컬렉션(Garbage Collection)가비지 컬렉션은 프로그래밍에서 더 이상 사용하지 않는 메모리, 즉 "쓰레기"가 된 메모리를 자동으로 회수하여 재활용하는 프로세스이다. 이는 개발자가 명시적으로 메모리를 해제해야 하는 부담을 덜어주고, 메모리 누수와 같은 문제를 예장하는 데 중요한 역할을 한다.가비지 컬렉션의 기본 원리가비지 컬렉션의 핵심 원리는 어떤 메모리 객체가 아직 사용되고 있는지, 아닌지를 판단하고 사용되지 않는 객체가 차지하고 있는 메모리를 회수하는 것이다. 가비지 컬렉션의 기본 원리는 다음과 같다.객체 추적 : 가비지 컬렉터는 프로그램 내의 모든 객체를 추적하고 관리한다. 각 객체가 어떤 변수나 다른 객체에 의해 참조되고 있는지 여부를 파악한다.도달 가능성 판단 : 가비지 컬렉터는..
Java 17의 등장Java 17 버전은 2021년 9월에 공개된 LTS(Long Term Supports) 버전으로 Java 11 LTS 등장이후 3에 등장한 LTS 버전이다.이번 Java 17버전의 다양한 변화사항중 눈에 띄는 점은 새로운 객체지향 패러다임을 제시하는 문법이 추가되었다는 점인데, 각각 Record, Seald Class이다. 이번 글에서 각각의 문법에 대해 자세히 알아보려 한다.RecordRecord 클래스는 데이터를 보유하는 데 특화된 간결한 클래스 선언 방식이다.전통적인 Java 클래스에서는 반복적으로 작성해야하는 보일러 플레이트(Boiler Plate)코드들이 다수 존재하는데, Record 클래스를 통해 해당 코드들을 자동으로 생산하도록 하여 개발자의 생산성을 크게 향상시킬 수 ..
이슈 사항Dev, PJ, QA, Stage 환경에서 이슈 발생시 원인 파악을 위해 보통 Local 환경으로 해당 이슈를 가져와서 디버깅을 진행해당 문제를 Local에서 재현 및 원인파악을 위한 리소스가 적지 않게 필요문제가 발생한 환경에 직접 붙어서 디버깅을 하고 싶다는 니즈를 해결하기위한 방법을 고민JDWP(Java Debug Wire Protocol)와 설정Java 에서는 JDWP를 통해 디버거와 JVM간 통신을 지원해준다.1. 원격 디버깅 설정원격 디버깅을 활성화하려면 JVM 옵션에 디버깅 관련 설정을 추가해야한다. Java8과 Java9 이상에서의 설정 방식이 약간 다르다.Java 실행 옵션에 아래 옵션을 추가한다.Java 8java -agentlib:jdwp=transport=dt_socket,..
들어가기 앞서최근 JVM을 보완하는 새로운 가상머신이 개발되었고 생각보다 많은 서비스에서 사용중이라는 소식을 들었다.Java는 다른 컴파일러 언어에 비해 느리다는 이야기를 들었고, 그 원인이 JVM에서 비롯되었다고 익히 알고 있던 와중 보완된 JVM을 통해 Java의 성능 문제를 해결할 수 있다는 사실에 흥미를 가지고 살펴 보았다. 기존 JVM의 한계사실 Java의 시작을 함께한 JVM을 대체하기 위한 시도는 과거에도 빈번했다.C, C++, Golang과 같은 컴파일러 기반의 언어는 컴파일 과정에서 바로 기계어로 번역되고 실행 파일을 만들어낸다. 그리고 컴파일 시에 코드 최적화까지 진행하여 인터프리터 대비 뛰어난 성능을 가지고 있다. 반면, Java는 플랫폼 종속적인 문제를 해결하기 위해 인터프리터(In..
2022년 진행된 if(kakao)에서 발표하신 카카오모빌리티 이형구님의 JVM Warm Up 세션을 보고 정리한 내용입니다. 계정 서버 배포 직후 발생하는 초기 API 응답 Latency 지연문제를 JVM에서 원인을 찾고 해결한 내용입니다.제가 작성한 모든 글의 내용과 사진은 if(kakao)2022에서 발표한 내용을 인용 및 사용하였습니다.계정 서비스계정 서비스는 높은 TPS를 특징으로 가지고 있으며, 빠른 응답 속도를 보장하는 것이 중요한 서비스이다.Java, Spring 기반으로 서비스가 작성되어 있으며, 오늘의 내용을 살펴보기 앞서 Java에 대해 잠깐 알아볼 필요가 있다. 작성된 Java Code를 중간언어인 Byte Code로 변환되며 War, Jar로 Archive되어 사용된다. 빌드된 ..
분산 트랜잭션(JTA)기반의 회원 시스템 개발오랫동안 농익은 레거시 시스템은 현재 시점에서 뜯어볼수록 의문이 많은 설계와 코드들이 참 많습니다.제가 속한 서비스의 회원 시스템도 마찬가지였습니다. 서비스를 이용하는 회원의 정보가 서로 다른 3개의 DB에 나뉘어 관리되고 있었습니다. 한명의 회원 정보가 여러 DB에 나뉘어 저장되는 것도 아니고, 유입된 채널에 따라 저장되는 DB가 물리적으로 분리되어 있었습니다.즉 온라인에서 가입한 고객은 오프라인에서 확인할 수 없고, 오프라인에서 가입한 고객은 온라인 서비스에서 접근할 수 없는 구조였습니다.이는 당연히 마케팅 측면이나 서비스의 확장성 측면에서 많은 어려움을 만들고 있었고, 이를 통합하기 위한 자칭 '통합회원 프로젝트'를 진행하게 되었습니다. 분리되어 있는 D..
