Spring Boot에서 @Transactional을 사용할 때 한 가지 흔히 겪는 함정이 있습니다. 바로, 같은 클래스 내에서 메소드를 호출하면 트랜잭션이 적용되지 않는다는 점입니다.
이번 포스팅에서는 이 현상이 왜 발생하는지, 그리고 어떻게 해결할 수 있는지 실제 예제를 통해 자세히 알아보겠습니다.
🧪 상황 예제: 트랜잭션이 안 먹는다?
@Service
public class AService {
@Transactional
public void methodA() {
methodB(); // 내부 호출
}
public void methodB() {
// 예외 발생
throw new RuntimeException("예외 발생!");
}
}
이 코드를 보면, methodA()는 @Transactional이 붙어 있어 트랜잭션이 시작되고, 그 안에서 호출되는 methodB()에서 예외가 발생하니 당연히 롤백될 것 같죠?
하지만 실제 실행해보면... 👉 롤백되지 않고 커밋됩니다!
🤔 왜 이런 일이 벌어질까?
이유는 Spring이 @Transactional을 프록시 기반 AOP로 구현하고 있기 때문입니다.
Spring의 트랜잭션 처리 흐름은 이렇게 됩니다:
Spring이 @Transactional이 붙은 클래스를 감싸는 프록시 객체를 만듭니다.
외부에서 해당 메소드를 호출하면 프록시가 감지하여 트랜잭션을 시작합니다.
하지만, 같은 클래스 안에서 메소드를 호출하면 프록시를 거치지 않고 this.method() 형태로 직접 호출하게 됩니다.
따라서 트랜잭션을 적용할 기회를 놓쳐버립니다!
📌 즉, 프록시가 개입해야 트랜잭션이 적용되는데, 내부 호출은 프록시를 생략하므로 적용되지 않음!
💡 쉽게 말해서?
마치 건물 입구에 감시카메라(프록시)가 달려 있다고 생각해보세요.
외부에서 들어오면 감시카메라가 감지해서 트랜잭션을 시작함
하지만 내부에서 옆방으로 이동하면 감시카메라가 그걸 감지 못함 → 트랜잭션 안 걸림
🛠 해결 방법
✅ 방법 1. 메소드를 다른 클래스로 분리
@Service
public class BService {
@Transactional
public void methodB() {
throw new RuntimeException("예외 발생!");
}
}
@Service
public class AService {
private final BService bService;
public AService(BService bService) {
this.bService = bService;
}
public void methodA() {
bService.methodB(); // 외부 호출 → 프록시 적용됨!
}
}
✅ 방법 2. ApplicationContext를 통해 프록시 자신을 가져와 호출
@Service
public class AService {
private final ApplicationContext context;
public AService(ApplicationContext context) {
this.context = context;
}
public void methodA() {
AService proxy = context.getBean(AService.class);
proxy.methodB(); // 프록시를 통한 호출
}
@Transactional
public void methodB() {
throw new RuntimeException("예외 발생!");
}
}
✅ 결론
@Transactional은 프록시를 거쳐야만 동작한다! 내부에서 자기 메소드를 호출하면 프록시를 거치지 않으므로 트랜잭션이 동작하지 않는다.
같은 클래스 내 메소드 간 호출에는 트랜잭션이 적용되지 않는다는 점, 항상 기억하고 설계하시길 바랍니다.
동기란 직렬적으로 작업을 수행하는 방식을 요청을 보낸 후 응답을 받아야지만 다음 동작이 이루어집니다.
즉, 다른 요청을 처리하는 동안 나머지 작업들은 대기 상태가 됩니다.
(출처:https://poiemaweb.com/es6-promise)
동기 실행의 동작 방식 및 처리 순서
콜 스택(Call Stack):
JavaScript 엔진은 현재 실행중인 모든 동기 작업을 콜 스택에 쌓습니다.
콜 스택은 LIFO(Last In, First Out) 구조로 가장 마지막에 추가된 작업이 가장 먼저 처리됩니다.
한 작업이 실행되면, 그 작업이 완료될 때 까지 콜 스택의 맨 위에 위치하며, 완료되면 콜 스택에서 제거됩니다.
블로킹(Blocking):
동기 작업 중 하나가 긴 시간을 필요로 하는 작업일 경우, 그 작업이 완료될 때까지 콜 스택이 차단됩니다.
이로 인해 후속 작업들은 차단 작업이 완료되기 전까지 실행될 수 없으며, UI업데이트나 다른 이벤트 처리가 지연될 수 있습니다.
작업 처리 순서:
작업1이 콜 스택에 들어가서 실행됩니다.
작업1에서 데이터를 서버에서 가져오는 동기작업을 요구하느 경우, 해당 작업이 완료되기 전까지 다음 작업은 실행되지 않습니다.
작업1이 완료되고 콜 스택에서 제거되면, 작업2가 콜 스택에 들어가 실행됩니다.
예시:
console.log('Task 1 시작'); // 콜 스택에 들어감
// 서버에서 데이터를 동기적으로 가져옴 (블로킹)
const data = getDataFromServer(); // 작업이 완료될 때까지 콜 스택 차단
console.log('Task 1 완료'); // 작업 1 완료 후 콜 스택에서 제거
console.log('Task 2 시작'); // 작업 1이 완료된 후 콜 스택에 들어감
doSomethingWith(data); // 작업 2 실행
console.log('Task 2 완료'); // 작업 2 완료 후 콜 스택에서 제거
비동기(Async)란?
비동기란 병렬적으로 작업 수행하는 방식으로 요청을 보낸 후 응답의 수락 여부와 상관없이 다음 작업을 동작하느 방식입니다. 비동기 요청시 응답 후 처리할 콜백함수를 함께 알려주어 작업이 완료되어 응답을 받으면 콜백함수가 호출됩니다.
(출처:https://poiemaweb.com/es6-promise)
비동기 동작 방식
메인 스레드: JavaScript코드가 실행될 때, 동기적으로 실행되는 작업들은 콜 스택(call stack)에서 처리되고 작업이 완료되면, 콜 스택에서 제거됩니다
이벤트 루프:비동기 작업은 바로 콜 스택에 추가되지 않습니다. 대신 해당 작업은 Web API 또는 C++ API에 의해 처리되고, 완료되면 콜백 함수가 테스크 큐(task queue) 또는 마이크로테스크큐(microtask queue)에 추가됩니다.
마이크로태스크 큐(Microtask Queue): Promise의 then, catch, finally 콜백이나 MutationObserver 콜백 같은 더 높은 우선순위를 가진 작업들이 대기하는 공간입니다.
이벤트 루프의 역할: 이벤트 루프는 콜 스택이 비어 있고 실행할 준비가 되었을 때, 태스크 큐 또는 마이크로태스크 큐에서 대기 중인 작업을 콜 스택으로 이동시킵니다. 마이크로태스크 큐의 작업은 태스크 큐의 작업보다 우선 처리됩니다.
비동기 작업 처리 순서
현재 실행 중인 동기 작업이 콜 스택에서 완료되고 제거됩니다.
콜 스택이 비어 있으면, 이벤트 루프는 마이크로태스크 큐에서 작업을 콜 스택으로 이동시켜 실행합니다.
마이크로태스크 큐가 비었을 때, 이벤트 루프는 태스크 큐에서 다음 작업을 콜 스택으로 이동시켜 실행합니다.
이 과정을 통해 JavaScript는 단일 스레드임에도 불구하고 비동기 작업을 효과적으로 관리하고 실행할 수 있습니다. 이러한 메커니즘 덕분에 JavaScript 애플리케이션이 동시성을 가지고 동작할 수 있으며, 사용자 인터페이스를 블로킹하지 않고 부드럽게 작동할 수 있습니다.
이와같이 컬렉션들의 상위 인터페이스로 SequenceCollection, SequencedSet, SequencedMap을 상속받아 사용해서 공통된 기능을 제공합니다.
SequencedCollection
sequencedCollection은 처음과 마지막 요소에 대한 공통된 기능을 제공합니다.
reversed()는 기존 컬렉션에서 iterator()나 forEach(), stream()와 같은 기능에서 역순으로 원소들을 처리할 수 있게 됩니다.
interface SequencedCollection<E> extends Collection<E> {
//기존 컬렉션에서 역순으로 원소들을 처리할 수 있게 됩니다.
SequencedCollection<E> reversed();
//첫번째에 원소를 추가합니다.
void addFirst(E);
//마지막에 원소를 추가합니다.
void addLast(E);
//첫번째 원소를 가져옵니다.
E getFirst();
//마지막 원소를 가져옵니다.
E getLast();
//첫번째 원소를 제거합니다.
E removeFirst();
//마지막 원소를 제거합니다.
E removeLast();
}
SequencedSet
SequencedSet은 중복된 원소를 갖지 않는 sequencedCollection에 해당하는 set입니다.
자바는 이를 JVM에서 처리하도록 해서 키워드를 명시해주지 않아도 JVM이 알아서 논블로킹 처리를 해주기 때문에 편리하게 사용할 수 있습니다.
스프링은 3 버전부터 지원해주는 걸로 알고 있습니다. 자세한 내용은 추후에 포스팅해서 정리하도록 하겠습니다.
3.Record
레코드에 타입 패턴을 함께 적용하여 레코드의 값을 손쉽게 처리할 수 있도록 도와줍니다.
자바 16에서는 instace of 연산자에 타입 패턴을 적용하여 패턴을 매칭시키도록 개선해서 하위 블록에 직접적으로 타입 캐스팅 할 필요가 없어졌습니다.
// Prior to Java 16
if (obj instanceof String) {
String s = (String)obj;
... use s ...
}
// As of Java 16
if (obj instanceof String s) {
... use s ...
}
자바 21부터는 레코드 타입에 대해 보다 간편하게 사용할 수 있도록 변경됩니다.
//Java 16
record Point(int x, int y) {}
static void printSum(Object obj) {
if (obj instanceof Point p) {
int x = p.x();
int y = p.y();
System.out.println(x+y);
}
}
//Java 21
tatic void printSum(Object obj) {
if (obj instanceof Point(int x, int y)) {
System.out.println(x+y);
}
}
위와 같은 패턴 매칭이 개선되어서 기존의 instance of에 if-else문법을 사용하지 않고 스위치 문에서 보다 간편하게 타입여부를 검사할 수 있습니다.
// Prior to Java 21
static String formatter(Object obj) {
String formatted = "unknown";
if (obj instanceof Integer i) {
formatted = String.format("int %d", i);
} else if (obj instanceof Long l) {
formatted = String.format("long %d", l);
} else if (obj instanceof Double d) {
formatted = String.format("double %f", d);
} else if (obj instanceof String s) {
formatted = String.format("String %s", s);
}
return formatted;
}
// As of Java 21
static String formatterPatternSwitch(Object obj) {
return switch (obj) {
case Integer i -> String.format("int %d", i);
case Long l -> String.format("long %d", l);
case Double d -> String.format("double %f", d);
case String s -> String.format("String %s", s);
default -> obj.toString();
};
}
4.Null Check
기존에는 파라미터가 null이면 NPE(NullPointerException)을 던지기 때문에, null에 대한 검사를 외부에서 수행했어야 하지만 자바21부터는 null에 해당하는 케이스를 내부에서 검사할 수 있게 되었다
// Prior to Java 21
static void testFooBarOld(String s) {
if (s == null) {
System.out.println("Oops!");
return;
}
switch (s) {
case "Foo", "Bar" -> System.out.println("Great");
default -> System.out.println("Ok");
}
}
// As of Java 21
static void testFooBarNew(String s) {
switch (s) {
case null -> System.out.println("Oops");
case "Foo", "Bar" -> System.out.println("Great");
default -> System.out.println("Ok");
}
}
5.case 세분화
case문은 여러 값에 대한 검사를 필요로 하기 때문에 상당히 복잡한 구조로 만들 수 밖에 없었지만 자바 21에서는 보기 좋게 변경되었습니다.
// As of Java 21
static void testStringOld(String response) {
switch (response) {
case null -> { }
case String s -> {
if (s.equalsIgnoreCase("YES"))
System.out.println("You got it");
else if (s.equalsIgnoreCase("NO"))
System.out.println("Shame");
else
System.out.println("Sorry?");
}
}
}
// As of Java 21
static void testStringNew(String response) {
switch (response) {
case null -> { }
case String s
when s.equalsIgnoreCase("YES") -> {
System.out.println("You got it");
}
case String s
when s.equalsIgnoreCase("NO") -> {
System.out.println("Shame");
}
case String s -> {
System.out.println("Sorry?");
}
}
}
6. enum개선
가독성이 좋게 enum이 개선되었습니다.
// As of Java 21
sealed interface CardClassification permits Suit, Tarot {}
public enum Suit implements CardClassification { CLUBS, DIAMONDS, HEARTS, SPADES }
final class Tarot implements CardClassification {}
static void exhaustiveSwitchWithoutEnumSupport(CardClassification c) {
switch (c) {
case Suit s when s == Suit.CLUBS -> {
System.out.println("It's clubs");
}
case Suit s when s == Suit.DIAMONDS -> {
System.out.println("It's diamonds");
}
case Suit s when s == Suit.HEARTS -> {
System.out.println("It's hearts");
}
case Suit s -> {
System.out.println("It's spades");
}
case Tarot t -> {
System.out.println("It's a tarot");
}
}
}
// As of Java 21
static void exhaustiveSwitchWithBetterEnumSupport(CardClassification c) {
switch (c) {
case Suit.CLUBS -> {
System.out.println("It's clubs");
}
case Suit.DIAMONDS -> {
System.out.println("It's diamonds");
}
case Suit.HEARTS -> {
System.out.println("It's hearts");
}
case Suit.SPADES -> {
System.out.println("It's spades");
}
case Tarot t -> {
System.out.println("It's a tarot");
}
}
}
ZGC는 짧은 지연 시간과 높은 확정성을 위해 고안된 GC 알고리즘으로 Java 15부터 프로덕션 환경에서 사용할 수 있게 되었다. 약한 세대 가설(Weak Generational Hypothesis)을 따라 대부분의 객체는 금방 죽기 때문에, 금방 죽는 Young 영역과 오래 살아남는 Old 영역을 분리하여 관리하는 것이 좋다. 그래서 Java 21에서는 이러한 방식을 통해 ZGC의 기능을 확장하여 성능을 개선시키고자 하였다. ZGC와 관련된 자세한 내용은 추후의 별도 포스팅을 통해 살펴볼 예정이다.
이후 릴리스에서 Windows 32bit x86 port를 제거하기 위해, 이를 Deprecate 시켰다. 이제 Windows 32bit 용 빌드를 구성하려고 시도할 때 오류 메세지가 표시된다.
$ bash ./configure
...
checking compilation type... native
configure: error: The Windows 32-bit x86 port is deprecated and may be removed in a future release. \\
Use --enable-deprecated-ports=yes to suppress this error.
configure exiting with result code 1
$
자바는 agent를 통해 애플리케이션 코드를 동적으로 변경하도록 지원해왔고, 이를 통해 애플리케이션을 모니터링하고 관찰하는 많은 방법들이 탄생하게 되었다. 대표적으로 Pinpoint와 같은 도구는 자바 에이전트를 기반으로 바이트 코드를 조작하여 모니터링을 돕는 APM 도구이다.
이러한 자바 애플리케이션을 프로파일링하는 정상적인 방법들은 애플리케이션이 실행될 때 불러와지고, 애플리케이션이 실행되는 중간에 불러와지는 경우가 거의 없다. 따라서 자바 21에서는 실행 중인 JVM에 에이전트가 동적으로 로드될 때 경고를 발행시키도록 수정되었다. 물론 JVM 시작 시에 에이전트를 로드하는 것은 경고를 발생시키지 않는다.
Java21에는 공개 키 암호화를 사용하여 대칭 키를 보호하는 암호화 기술인 KEM(Key Encapsulation Mechanism) API가 도입되었다. 기존의 기술은 무작위로 생성된 대칭 키를 공개 키로 암호화하는 것이지만, 패딩이 필요하고 보안을 증명하기 어려울 수 있다. 대신 KEM은 공개 키의 속성을 사용하여 패딩이 필요 없는 관련 대칭 키를 도출한다.
KEM은 양자 공격을 방어하기 위한 핵심 도구가 될 것이다. 다른 보안 제공업체들은 이미 표준 KEM API에 대한 필요성을 표명했고, 자바 역시 이를 공식적으로 도입하기로 결정하였다.
package javax.crypto;
public class DecapsulateException extends GeneralSecurityException;
public final class KEM {
public static KEM getInstance(String alg)
throws NoSuchAlgorithmException;
public static KEM getInstance(String alg, Provider p)
throws NoSuchAlgorithmException;
public static KEM getInstance(String alg, String p)
throws NoSuchAlgorithmException, NoSuchProviderException;
public static final class Encapsulated {
public Encapsulated(SecretKey key, byte[] encapsulation, byte[] params);
public SecretKey key();
public byte[] encapsulation();
public byte[] params();
}
public static final class Encapsulator {
String providerName();
int secretSize(); // Size of the shared secret
int encapsulationSize(); // Size of the key encapsulation message
Encapsulated encapsulate();
Encapsulated encapsulate(int from, int to, String algorithm);
}
public Encapsulator newEncapsulator(PublicKey pk)
throws InvalidKeyException;
public Encapsulator newEncapsulator(PublicKey pk, SecureRandom sr)
throws InvalidKeyException;
public Encapsulator newEncapsulator(PublicKey pk, AlgorithmParameterSpec spec,
SecureRandom sr)
throws InvalidAlgorithmParameterException, InvalidKeyException;
public static final class Decapsulator {
String providerName();
int secretSize(); // Size of the shared secret
int encapsulationSize(); // Size of the key encapsulation message
SecretKey decapsulate(byte[] encapsulation) throws DecapsulateException;
SecretKey decapsulate(byte[] encapsulation, int from, int to,
String algorithm)
throws DecapsulateException;
}
public Decapsulator newDecapsulator(PrivateKey sk)
throws InvalidKeyException;
public Decapsulator newDecapsulator(PrivateKey sk, AlgorithmParameterSpec spec)
throws InvalidAlgorithmParameterException, InvalidKeyException;
}
Homebrew패키지 매니저를 이용해서 MariaDB Server를 macOS (이전 Mac OS X) 설치할 수 있습니다.
MariaDB Server는 미리 컴파일된 Homebrew "bottle" 패키지로 이용 가능하며, 소스 빌드가 필요 없어 시간을 절약해줄 수 있습니다.
Homebrew 설치 후에는 MariaDB Server 는 다음과 같이 설치 가능합니다.
- brew install mariadb
설치 후에는 다음으로 MariaDB Server를 시작합니다.:
- mysql.server start
MariaDB Server 자동 시작하려면 다음과 같이 Homebrew 서비스 기능을 이용할 수 있습니다. (이 서비스 기능은launchd의 launchctl 유틸리티를 이용합니다) :
- brew services start mariadb
MariaDB Server 시작후에는 사용자 계정으로 로그인하면 됩니다.:
- mysql
또는 루트 계정으로 로그인할 수도 있습니다.:
- sudo mysql -u root
MariaDB 업그레이드
우선 brew 를 업데이트 합니다
- brew update
그리고, 다음과 같이 MariaDB Server를 업데이트 합니다. :
- brew upgrade mariadb
소스로부터 MariaDB Server 빌드
"bottled" MariaDB Server 패키지는 Homebrew로도 가능하지만 소스로부터 MariaDB를 빌드할 수도 있습니다. 이는 bottle 패키지에 포함되지 않은 다른 버전의 특징적인 기능들을 사용하고자 할때 유용합니다.
bottle 패키지에 포함되지 않은 두 개의 컴퓨넌트들은 CONNECT와 OQGRAPH 엔진인데, 이는 비표준 의존성을 가지고 있기 떄문입니다. 이 엔진으로 MariaDB Server 를 빌드하려면 우선,boost와judy를 설치해야 합니다. 2016년 12월 현재, judy는 Homebrew "boneyard" 단계이나 macOS Sierra 상에서 동작합니다. 의존성을 가진 상태로 서버를 빌드 및 설치하려면 다음 단계를 따라주세요.:
또한 Homebrew를 이용하여 MariaDB Server의 프리-릴리즈 버전을 빌드 및 설치할 수 있습니다 (예를 들어, MariaDB Server 10.2, MariaDB Server 10.1의 가장 최신의 GA 버전). MariaDB Server 의 "개발" 버전을 빌드 및 설치하려면 다음과 같이 합니다.:
Java 8에는 AWTUtilities 클래스가 있는데, 그에 따라 어떤 프로그램도 중단될 수 있으므로 사용하지 않는 것이 좋습니다.
Java 11에서는 AWTUtilities 클래스를 사용 불가
문자열 메서드가 적습니다.
isBlank(), line(), repeat(n), stripLeading(), stripTrailing(), stripTrailing()과 strip()과 같은 몇 가지 새로운 문자열 방법이 도입된다.
람다 파라미터에는 특수 변수가 사용되지 않습니다.
Java 11을 사용하면 람다 식에 사용할 var 변수를 사용할 수 있습니다.
Java Deployment Technologies는 Java 8에서 사용할 수 있습니다.
Java Deployment Technologies는 Java 11에서 제거됩니다.
JMC 및 JavaFX는 Oracle JDK에서 사용할 수 있습니다.
JMC와 JavaFX는 Java 11의 Oracle JDK에서 제거됩니다.
파일에 적합한 방법이 없습니다.
자바 11에서는 writeString(), readString(), isSameFile()과 같은 다양한 메소드가 있어 파일에 대해 여러 작업을 수행할 수 있다.
패턴을 인식할 수 없습니다.
패턴 인식은 asMatchPredicate() 메서드의 도움으로 가능합니다.
Java 11
새로운 String 메서드 추가
- strip(): 문자열 앞, 뒤의 공백 제거.
- stripLeading(): 문자열 앞의 공백 제거.
- stripTrailing(): 문자열 뒤의 공백 제거.
trim() 과의 차이점은, trim() 은 U+0020 이하의 값만을 공백으로 인식하여 제거한다 (tab, CR, LF, 공백). 하지만 유니코드에서는 이 외에 다양한 공백 문자가 존재하는데, 이를 처리하기 위해서는 기존에는 Character.isWhitespace(int) 를 사용해야 했다. Java 11 부터는 strip() 으로 편하게 처리할 수 있다.
그리고 성능도 수 배 빠른 것으로 알려짐.
- isBlank(): 문자열이 비어있거나 공백만 포함되어 있을 경우 true 를 반환한다. 즉, String.trim().isEmpty() 호출 결과와 같다.
- Path writeString(Path, String, Charset, OpenOption): 파일에 문자열을 작성하고 Path로 반환한다. 파일 오픈 옵션에 따라 작동 방식을 달리하며, charset을 지정하지 않으면 utf-8 이 사용된다. (오버로딩 메서드로writeString(Path, String, OpenOption) 존재.)
- String readString(Path, Charset): 파일 전체 내용을 읽어서 String으로 반환하고, 파일 내용을 모두 읽거나 예외가 발생하면 알아서 close 한다. charset을 지정하지 않으면 utf-8 이 사용된다. (오버로딩 메서드로 readString(Path) 존재.)
- boolean isSameFile(Path, Path): 두 Path 가 같은 파일을 가리키면 true, 아니면 false 를 반환한다. 파일이 실제로 존재하지 않아도, Path 를 기준으로 해서 같은 위치면 true 로 판단한다.
Pattern.asMatchPredicate()
- Java 8 의 asPredicate는 matcher().find() 를 사용하는 것에 반해, asMatchPredicate() 는 matcher().match() 를 사용하는 Predicate를 반환한다.
Predicate.not(Predicate)
- 인자로 받은 Predicate의 부정형 Predicate를 반환한다.
람다 파라미터로 var 사용:
(var n1, var n2) -> n1 + n2
- Java 8 에 등장했으나 Java 10 에서 사라졌다가 Java 11 에서 복귀한 기능.
- 람다는 타입을 스킵할 수 있는데 이걸 사용하는 이유는, @Nullable 등의 어노테이션을 사용하기 위해 타입을 명시해야 할 때.
- var 를 사용하려면 괄호를 써야하며, 모든 파라미터에 사용해야 하고, 다른 타입과 혼용하거나 일부 스킵은 불가능함:
(var s1, s2) -> s1 + s2 // 안 됨. s2 에도 var 필요.
(var s1, String y) -> s1 + y // 안 됨. String 과 혼용 불가.
var s1 -> s1 // 안 됨. 괄호 필요.
Optional.isEmpty()
- Optional이 비어있을 때 true 반환.
TimeUnit.convert(Duration)
TimeUnit c = TimeUnit.DAYS;
c.convert(Duration.ofHours(24)); // 2
c.convert(Duration.ofHours(72)); // 3
Nest-Based Access Control (JEP 181)
- Java 10 까지 nested 클래스에서 자신, 혹은 outer 클래스의 private 멤버에 리플렉션을 통한 접근을 시도하면 IllegalAccessException 이 발생했고, 이를 피하기 위해 setAccessible(true) 을 호출해야만 했음.
- Java 11 부터는 setAccessible 없이 private 멤버를 호출할 수 있음.
- java.lang.Class 에 다음 메서드들이 추가됨.
- getNestHost(): nested 클래스에서 호출하면 자신을 감싸고 있는 outer 클래스를 반환하고, outer 클래스에서 호출하면 자신을 반환.
- boolean isNestmateOf(Class): 자신이 아규먼트로 받은 Class의 nested 클래스일 때 true 를 반환함.
- Class[] getNestMembers(): 자신을 포함하여 중첩 관계에 있는 모든 클래스를 배열로 반환함. (outer, siblings)
Epsilon Garbege Collector (No-Op GC, JEP 318)
- JVM으로 하여금 메모리 할당을 관리하지만, 사용된 메모리를 재사용하지 않도록 함. 메모리를 다 사용하면 OutOfMemory가 발생하고 JVM은 셧다운된다.
- 어플리케이션 테스트에 사용됨. GC는 어플리케이션과 함께 작동하며, 오버헤드가 있어 어플리케이션 성능에 영향을 준다. No-OP GC를 적용하여 GC를 배제함으로써 순수 어플리케이션의 성능, 메모리 부하 등을 테스트할 수 있도록 한다. GC 적용 시의 성능과 비교하여 GC의 영향도를 측정할 수 있다.
- 짧은 시간 수행하고 종료되는 어플리케이션에 사용됨. 간단히 작동하고 마치는, 메모리 부하가 크게 염려되지 않는 어플리케이션에 적절하게 사용될 수 있음.
