외부 함수 및 메모리 (FFM) API는 MemorySegment를 도입하여 안전하게 오프-힙 메모리에 접근할 수 있도록 합니다. 각 세그먼트는 라이프사이클을 정의하는 MemorySession(또는 최신 버전의 Arena)과 연관되어 있습니다. 아레나가 닫히면 ScopedMemoryAccess 계층이 모든 관련 세그먼트를 "활성 아님"으로 표시합니다.
이후의 접근 시도는 ScopedMemoryAccess.Scope 검사를 촉발하여 즉시 IllegalStateException을 발생시킵니다. 네이티브 작업이 진행되는 동안 가비지 수집기가 세그먼트를 회수하지 못하도록 하기 위해 JVM은 암묵적으로 reachabilityFence 의미론을 사용합니다. 컴파일러는 중요한 경계에서 유지 관리 장벽을 삽입하여 세그먼트 객체가 네이티브 호출이 완료될 때까지 강하게 접근 가능하도록 보장합니다.
이 조정은 **close()**를 통한 명시적 결정론적 정리를 가능하게 하면서 가비지 수집기가 세그먼트를 조기에 최종화하는 경우 발생할 수 있는 사용 후 해제 오류를 방지합니다. 이 설계는 매 접근마다 수동 동기화가 필요하지 않으면서도 메모리 안전성을 유지하도록 합니다. 이 아키텍처적 선택은 수동 메모리 관리와 자바의 자동 가비지 수집 패러다임 간의 간극을 메웁니다.
MemorySegment를 사용하여 C++ 거래소 게이트웨이와 공유되는 오프-힙 버퍼에 매핑된 시장 데이터를 처리하는 고주파 거래 애플리케이션을 고려해 보십시오. 문제는 여러 스레드가 배경 유지 관리 스레드가 주기적으로 버프를 새로 고칠 때 가격 업데이트를 읽으려 시도할 때 발생합니다. 이때 오래된 Arena를 닫고 새로 할당합니다. 적절한 시간적 안전성이 없으면, 리더 스레드는 기반 메모리가 운영 체제에 반환된 세그먼트에 접근하려 할 수 있으며, 이는 JVM 충돌이나 무음 데이터 손상을 초래할 수 있습니다.
추가로 고려된 솔루션은 AtomicInteger를 사용한 명시적 참조 카운팅이었습니다. 각 읽기 작업은 카운터를 증가시키고 작업이 완료되면 감소시킵니다. 장점은 단순한 논리와 즉각적인 누수 탐지입니다. 하지만 단점으로는 높은 부하에서 원자 변수의 심각한 경합과 가비지 수집기와의 통합 실패가 있습니다. 잊혀진 감소는 여전히 메모리 누수를 일으키고, 네이티브 코드가 원시 포인터를 보유하는 동안 아레나가 닫히는 것을 방지하지 않습니다.
또 다른 접근 방식은 모든 접근을 포장하는 try-with-resources 블록을 포함하여 아레나가 작업 중에 열린 상태를 유지하도록 하는 것입니다. 장점은 결정론적 범위와 깔끔한 구문입니다. 단점은 단기 작업에 대해 빈번한 아레나의 닫힘 및 열림이 발생하여 초당 수천 개의 세그먼트를 할당할 때 비용이 과도하게 발생합니다. 또한, 이 패턴은 자바의 범위를 초과하며 지속될 수 있는 네이티브 코드의 비동기 콜백으로부터 보호할 수 없습니다.
선택된 솔루션은 적절한 reachabilityFence 배치와 스코프 액세스 검사를 통해 **Arena.ofShared()**를 활용했습니다. 아레나 닫힘을 전담 유지 관리 스레드에 한정하고 모든 읽기 작업이 역참조 이전에 세그먼트의 살아 있는 상태를 검증하도록 하여 시스템은 경합 조건을 제거했습니다. ScopedMemoryAccess 메커니즘은 빠른 경로에서 제로 비용 검사를 제공하고 JVM의 도달 가능성 보장이 GC 간섭을 방지했습니다. 그 결과, 네이티브 충돌이나 메모리 누수 없이 초당 수백만 개의 메시지를 처리하는 안정적인 시스템이 구축되었습니다.
왜 MemorySegment가 세그먼트가 명시적으로 제한되지 않았음에도 WrongThreadException을 발생시키며, Arena 유형이 스레드 제한 의미론을 어떻게 결정하는가?
많은 후보자들은 모든 세그먼트가 기본적으로 스레드 안전하다고 가정합니다. 그러나 실제로 **Arena.ofConfined()**는 생성 스레드에서만 접근할 수 있는 세그먼트를 생성하며, 이는 ScopedMemoryAccess의 스레드-ID 점검에 의해 시행됩니다. **Arena.ofShared()**는 스레드 간 접근을 허용하지만 외부 동기화를 요구합니다. 예외는 제한된 세그먼트의 주소가 람다 또는 콜백을 통해 다른 스레드에 전달될 때 발생합니다.
네이티브 호출 중 오프-힙 리소스의 유효성을 보장할 때 reachabilityFence 메커니즘이 PhantomReference와 어떻게 다른가?
후보자들은 종종 이 두 메커니즘을 혼동합니다. PhantomReference는 객체가 도달할 수 없게 된 후 사후 정리를 허용하지만, 이는 활성 작업 중 사용 후 해제를 방지하기에는 너무 늦습니다. reachabilityFence는 fence가 실행될 때까지 객체가 강하게 접근 가능하도록 유지하는 컴파일러 삽입 장벽으로 작용합니다. FFM에서는 JVM이 MemorySegment 접근자 주변에 이러한 장벽을 자동으로 삽입하여, 사용자 코드에서 수동으로 위치를 지정할 필요 없이 세그먼트가 네이티브 메모리 접근 동안 살아 있음을 보장합니다.
MemorySegment를 직접 닫는 것과 그 부모 Arena를 닫는 것 사이의 차별점은 무엇이며, 아레나를 닫으면 모든 파생 세그먼트가 동시에 무효화되는 이유는 무엇인가?
세그먼트가 독립 자원이라는 일반적인 오해가 있습니다. 사실, slice() 또는 **reinterpret()**를 통해 파생된 세그먼트는 부모 아레나와 동일한 ScopedMemoryAccess.Scope를 공유합니다. **Arena.close()**가 호출되면 전체 범위를 무효화하여 모든 파생 세그먼트에 전파됩니다. 개별 세그먼트를 닫는 것은 특정 보기만 비효율적으로 표시하지만, 기초 메모리는 아레나가 닫힐 때까지 할당된 상태로 유지됩니다.