• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    해결됨

static inner class 에 대해 궁금합니다

23.05.12 21:32 작성 조회수 891

0

안녕하세요.


DTO를 static inner class로 작성했을 때 멀티스레딩 환경에서 동시성 위험이 있는지에 대해 궁금합니다.

예를 들어 아래와 같이 DTO를 작성하고 사용한다고 했을 때

public class UserDto {
	public static class Request1 {
		int id;
		String name;
		@Builder
		private Request1(int id, String name){
			this.id = id;
			this.name = name;
		}
	} 
	public static class Request2 {
		private final int id;
		private final String name;
		@Builder
		private Request2(int id, String name){
			this.id = id;
			this.name = name;
		}
	}
}

우선 기본적으로 static inner class의 경우 outer 클래스의 인스턴스가 뜨지 않아도 inner 클래스의 인스턴스를 띄울 수 있습니다.

그래서 Builder 패턴을 통해 Request1의 인스턴스를 생성한다면, 롬복의 @Builder를 까보면 결국 public static class RequestBuilder 에서 Request 객체를 만들고 이를 반환하는 방식으로 되어 있는데 반환하고 RequestBuilder 객체는 GC에 반환된다고 들었습니다.

어쨌든 그래서 Request1의 객체가 생성되면 멤버 변수가 final이 아니기에 수정될 여지가 존재하는데, Heap 메모리에 새로운 객체가 생길것이고 Heap 메모리에 생성된 객체가 수정될 수 있다면 다른 스레드가 객체의 상태를 변경할 수 있으니 thread-safe 하지 않을 수 있겠다는 생각이 들었습니다.

 

만약 Request2처럼 멤버 변수들을 final로 사용한다면 thread-safe 해질 수 있지 않나 라는 생각인데 맞는 생각인지 잘 모르겠어서 질문 남깁니다.

 

감사합니다.

 

 

 

 

답변 1

답변을 작성해보세요.

2

David님의 프로필

David

2023.05.13

안녕하세요. brian654321님, 공식 서포터즈 David입니다.

질문의 요지는 static inner class와 별개로 private final을 붙인 필드와 아닌 필드의 차이를 동시성 관점으로 봤을 때 스레드 세이프하냐 아니냐로 이해했습니다.

일단, 코드 작성시 매번 새로운 객체를 생성하고 있고, 상태를 변경하는 코드를 작성하지 않는다면 스레드 세이프 하다고 볼 수 있을 것 같습니다.

다만, Request1의 경우 필드의 접근 제어자가 Default이기 때문에 같은 패키지 내에서는 필드에 바로 접근할 수 있습니다. private으로 막고 생성자를 통해서만 필드를 초기화 하도록 한다면 상태 변경에 대해 비교적 자유롭다고 볼 수 있겠습니다.

또한 상태를 변경하는 메서드 유무의 관점으로 Reuqest1, Request2 본다면 둘 다 해당되지 않기 때문에 리플렉션을 사용하는 게 아니라면 최초 생성 이후 상태가 변경될 순 없습니다.

감사합니다.