• 자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원이 많다.

    ◦  InputStream, OutputStream 등의 IO 라이브러리

    ◦ 터미널 등에서 명령어를 이용해 메모장을 열고, close 하지 않은 상태에서 메모장 파일을 마우스 클릭으로 실행해보면
        위와 같은 에러메세지를 확인할 수 있다.

    ◦ java.sql.Connection 등의 JDBC 사용을 위한 라이브러리

• 어떠한 이유(오류 또는 개발자의 실수)에 의해서 close가 안되면, 프로그램에 문제가 생길 수 있다.

• 이런 자원의 상당수가 안전망으로 finalizer를 활용하고 있긴 하나, 그리 믿을만하지는 못하다.


자원의 닫힘을 보장해주는 수단 : try-finally

• try와 finally는 짝꿍으로 붙어다녀야 하며, try블록에서 예외가 나던/나지않던 finally 안의 구문은 실행된다.

static String firstLineOfFile(String path) throws IOException {
    BufferedReader br = new BufferedReader(new FileReader(path));
    try { return br.readLine(); }
    finally { br.close(); }
} // read 만 하고 close 하는 경우
static void copy(String src, String dst) throws IOException {
    InputStream in = new FileInputStream(src);
    try { OutputStream out = new FileOutputStream(dst);
        try {
            byte[] buf = new byte[BUFFER_SIZE];
            int n;
            while ((n = in.read(buf)) >= 0) out.write(buf, 0, n);
        } finally { out.close(); }
    } finally { in.close(); }
} // read 도 하고 write 도 하고싶은 경우 : close 를 2번 해줘야 한다.

• 코드의 가독성이 너무 나쁘다. 자원이 100개가 되면 try-finally가 100개가 생긴다.

static String firstLineOfFile(String path) throws IOException {
	  BufferedReader br = new BufferedReader(new FileReader(path));
	  try { return br.**readLine**(); }
		finally { br.**close**(); }
}

• 특히 예외는 try 블록과 finally 블록 모두에서 발생할 수 있는데, 위 예시에서 기기에 문제가 생기는 경우

    ◦  readLine 메서드가 먼저 예외를 던진다 : 파일을 읽을 수 없습니다.

    ◦  그 다음 close 메서드가 예외를 던진다 : 파일을 close 할 수 없습니다.

     → 이런 상황이 발생하면 스택 추적 내역에 첫번째 예외에 관한 정보는 남지 않는다 : 디버깅이 어려워짐


해결책의 등장 : try-with-resources

• try 안에 파라미터로 자원을 넘겨주는 방식

• try 문에서 선언된 객체들에 대해서 try가 종료될 때 자동으로 자원을 해제해주는 기능이 있다.

• 먼저 이 구조를 사용하려면 해당 자원이 AutoCloseable 인터페이스를 구현해야 한다.

    ◦  AutoCloseable 인터페이스 : void 타입의 close 메서드 하나만 덩그러니 정의된 인터페이스

public interface AutoCloseable { void close() throws Exception; }

    ◦  public interface AutoCloseable { void close() throws Exception; }

    ◦  try-with-resources가 모든 객체의 close를 호출해주지는 않음

    ◦  AutoCloseable을 구현한 객체만 close가 호출된다.

public abstract class BufferedReader implements AutoCloseable { ... }
static String firstLineOfFile(String path) throws IOException {
    try (BufferedReader br = new BufferedReader(new FileReader(path))) {
				return br.readLine();
		}
}
static void copy(String src, String dst) throws IOException {
    try (Input in = new FileInput(src); Output out = new FileOutput(dst)) {
        byte[] buf = new byte[BUFFER_SIZE];
        int n;
        while ((n = in.read(buf)) >= 0) out.write(buf, 0, n);
    }
}

• 코드의 가독성이 훨씬 좋아지고 문제 진단에도 훨씬 유리하다.

• readLine 과 close 에서 모두 예외가 발생하면 먼저 발생한 readLine의 예외가 기록되고, close에서 발생한 예외는 숨겨지기 때문

• 이렇게 숨겨진 예외들은 스택 추적 내역에 숨겨졌다(suppressed)는 꼬리표를 달고 출력된다.

    ◦  Throwable의 getSuppressed 메서드를 이용하면 프로그램 코드에서 가져올 수도 있다.

void addSuppressed(Throwwable exception)
public final Throwable[] getSuppressed()

    ◦  숨겨지는것 보단, 더 자세한 출력이 진짜 목적


try-with-resources 와 함께 쓰이는 catch 구문

• try-with-resources와 catch 절을 함께 쓰면 try 문을 중첩하지 않고도 다수의 예외를 처리할 수 있다.

try {
   // 프로그램에서 사용하는 일반적인 코드를 입력
   // 코드 실행 중 에러가 나면 그 자리에서 중단되고 catch문으로 이동
   // 오류가 없다면 try 안의 구문을 모두 실행한다.
} catch(Exception e) {
   // try에서 오류가 나면 catch안의 내용을 실행
   // try에 오류가 없다면 catch는 실행되지 않는다.
}
static String firstLineOfFile (String path, String defaultVal){
    try (BufferedReader br = new BufferedReader(new FileReader(path))) {
        return br.readLine();
    } catch (IOException e) { return defaultVal; }
} // 파일을 여는 것에 실패하거나, 데이터를 읽지 못했을 때 예외 대신 기본값을 반환하도록 수정된 코드

• 예외처리란, 프로그래머가 예기치못한 예외의 발생에 미리 대처하는 코드를 작성하는 것

    ◦  (나쁜)사용자가 발생시키는 예외에 대해, 개발자가 미리 대처를 해줄 수 있다.

    ◦  실행중인 쓰레드비정상적인 종료를 막고 상태를 정상상태로 유지하는 것이 목적

• 예외가 처리되지 못한경우, 쓰레드은 비정상적으로 종료되며 처리되지 못한 예외의 원인을 JVM의 예외처리기

    (UncaughtExceptionHandler)가 화면에 출력해준다.

Garbage Collector

• 자바는 Garbage Collector 를 갖춘 언어

 메모리를 직접 관리해야하는 C/C++과 달리, 다 쓴 객체를 알아서 회수해준다.

 JVM에서 GC의 스케줄링을 담당

 객체는 힙 영역에 저장되고 스택 영역에 이를 가리키는 주소값이 저장되는데 참조되지 않는
    (자신을 가리키는 포인터가 없는, unreachable) 객체를 메모리에서 제거한다.

Person person = new Person();
person.setName("Mang");

// garbage 발생
person = new Person();
person.setName("MangKyu");

메모리 누수

• 컴퓨터 프로그램이 필요하지 않은 메모리를 계속 점유하고 있는 현상

• Old 영역에 계속 누적된 객체로 인해 Major GC가 빈번하게 발생하게 되면서 성능 저하를 불러온다.

• 디스크 페이징이나 OutOfMemoryError 를 일으켜 프로그램이 종료될 수도 있다.

public Object pop() {
	if(size==0) throw new EmptyStackException();
	return elements[--size];
}
public Object pop() {
	if(size==0) throw new EmptyStackException();
	Object result = elements[--size];
	elements[size] = null;
	return result;
}

해결 방법(1) : null 처리

• 해당 참조를 다 썼을 때 null 처리(참조 해제)를 해주는 방법

• 사용이 끝난 참조에 실수로 접근하는 경우 NullPointerException을 내주는 효과도 있다.

• 예외적인 경우에만 사용하자 : 자기 메모리를 직접 관리하는 클래스의 경우

    ◦  그 외에는 프로그램을 필요 이상으로 지저분하게 만들 뿐


해결방법(2) : 참조를 담은 변수를 유효 범위(scope) 밖으로 밀어내기

• 변수의 범위를 최소가 되게 정의하자

for(int i=0;i<10;i++){...} // i 의 범위를 10 미만으로 제한했다.

기타 메모리 누수가 발생하는 상황 및 해결책

1) 캐시(cache)에 객체를 넣어두고 잊어버리는 경우

• java.lang.ref 패키지의 WeakReference 클래스를 사용하는 방법

WeakReference<Integer> A = new WeakReference<Integer>(new Integer(1));
Integer B = A.get() // B = 1
B = null; 
C = A.get();
// Integer 객체를 가리키는 참조가 WeakReference 객체 A 뿐 : 1은 GC 대상

• WeakHashMap 을 사용하는 방법

    ◦  일반적인 HashMap의 경우 일단 Map안에 Key와 Value가 put되면 사용여부와 관계없이 해당 내용은 삭제되지 않는다.

    ◦  WeakReference를 이용해 HashMap의 Key를 구현하는 WeakHashMap을 이용하자.

• 백그라운드 스레드(ScheduledThreadPoolExecutor)를 활용하는 방법

    ◦  어떤 작업을 일정 시간 지연 후에 수행하거나, 일정 시간 간격으로 주기적으로 실행해야 할 때 사용

• 캐시에 새 엔트리를 추가할 때 부수 작업을 수행하는 방법

    ◦  LinkedHashMap 을 사용하는 방법 (removeEldestEntry)(10)

         - 일정 사이즈가 차면 가장 오래된 값을 지우고, 그 자리에 방금 들어온 값을 대체 한다.

 

2) 콜백(callback) / 리스너(listener)

• 피호출자(Callee)가 호출자(Caller)를 다시 호출하는 함수 : 콜백함수

    ◦  비동기적 처리를 하기 위한 디자인 패턴의 한 종류

• 콜백을 등록만 하고 명확히 해지하지 않는 경우 메모리 누수가 발생한다

• 콜백을 약한 참조로 저장하면 가비지 컬렉터가 즉시 수거해간다.

    ◦  WeakHashMap 에 키로 저장하는 방법


참고자료

 

[JAVA] 가비지 컬렉터(Garbage Collector)

객체의 소멸과 가비지 자바는 객체를 생성하는 new 연산자는 있지만 객체를 소멸시키는 연산자는 없음 => 개발자가 마음대로 객체를 소멸시킬 수 없음 객체 소멸이란 new에 의해 생성된 객체 공간

transferhwang.tistory.com

 

클래스와 자원

• 클래스는 보통 하나 이상의 자원에 의존한다.

    ◦  의존한다 = 관계성이 있다 / 자원이 클래스의 동작에 영향을 준다.

    ◦  예 : 맞춤법 검사기는 사전 객체에 의존한다. (사전에 존재하는 단어가 아니면 밑줄)


하나 이상의 자원에 존재하는 클래스(1) : 맞춤법 검사기의 잘못된 구현 방식

public class SpellChecker {
	private static final Lexicon dictionary = ... ;
	private SpellChecker() {} // 객체 생성 방지용 생성자

	public static boolean isValid(String word) { ... }
}
public class SpellChecker {
	private final Lexicon dictionary = ... ;

	public static SpellChecker INSTANCE = new SpellChecker();
	private SpellChecker() {}
	
	public static boolean isValid(String word) { ... }
}

• 위의 두가지 방식은 클래스가 단 하나의 사전 객체에만 의존한다고 가정하고 있다 BAD

    ◦  일반적으로 사전은 하나로 구성되어 있지 않고, 여러개로 나누어져 있다. (전세계 언어 사전 X)

    ◦  제안) final 한정자를 제거하고, 다른 사전으로 교체하는 메서드를 추가?

         -  어색하고 오류를 내기 쉽다 + 멀티스레드 환경에서는 사용할 수 없다.

public class SpellChecker {
	private static Lexicon dictionary = ...;

  public static SpellChecker INSTANCE = new SpellChecker();
	private SpellChecker() {}

	public static boolean isValid(String word) { ... }
  public static void changeDictionary(Lexicon new) { dictionary = new; }
}

의존 객체 주입 방법

• 해당 클래스의 인스턴스를 생성할 때 생성자에게 필요한 자원을 넘겨주는 방법

public class SpellChecker {
		private final Lexicon dictionary;
		
		public SpellChecker(Lexicon dictionary){
				this.dictionary = Objects.requireNonNull(dictionary);
		}
		public boolean is Valid(String word) { ... }
}
public class KoreanDict implements Lexicon { ... }
public class EnglishDict implements Lexicon { ... }

Lexicon kordict = new KoreanDict();
Lexicon engdict = new EnglishDict();

SpellChecker korchecker = new SpellChecker(kordict);
SpellChecker engchecker = new SpellChecker(engdict);

korcheker.isVaild("한국말");
engcheker.isVaild("English");

불변성을 보장하기 때문에 여러 클래스가 같은 의존 객체들을 공유할 수 있다

    ◦  this.dictionary 로 받아서 사용했기 때문

• 정적 팩토리와 빌더에서도 이런 방식으로 의존 객체를 넘겨줄 수 있다.


응용 : 생성자에 자원 팩토리를 넘겨주는 방식 (팩토리 메서드 패턴)

 팩토리 = 호출될 때 마다 특정 타입의 인스턴스를 만들어주는 객체

 Supplier<T> 인터페이스 = 팩토리의 완벽한 표현

    ◦  함수형 인터페이스 : 매개변수는 없고, 반환값만 있다.

~~String supplier= new String();
supplier =  "Hello World";~~

Supplier<String> supplier= () -> "Hello World";

String result = supplier.get();
System.out.println(result); // Hello World

• Supplier<T>를 입력으로 받는 메서드는 한정적 와일드카드 타입(bounded wildcard type)을 사용하여
    팩터리의 타입 매개변수를 제한해야 한다.

    ◦  와일드 카드 : 제네릭 코드에서 물음표(?) 로 표기되어 있는 것. 아직 알려지지 않은 타입 의미.

    ◦  한정적 와일드카드 : (?) 가 무언가를 extend 한다.

    ◦  명시한 타입의 하위 타입이라면 무엇이든 생성할 수 있는 팩토리를 넘길 수 있게 됨

Mosaic create(Supplier<? extends Tile> tileFactory) { ... }

 


의존 객체 주입 방식의 장점

• 코드의 유연성과 재사용성, 테스트의 용이성을 개선시킴

• 그러나 의존성이 많은 큰 프로젝트에서는 코드를 어지럽게 만들기도 함

    ◦  Spring 등의 의존 객체 주입 프레임워크를 사용하는 것이 좋음

          -  의존 객체를 직접 주입하도록 설계된 API를 사용한다.

@Controller
public class MemberController {
		private final MemberService memberService;

		@Autowired
		public MemberController(MemberService memberService) {
				this.memberService = memberService;
		}
}

• 생성자에 @Autowired가 있으면 스프링이 연관된 객체를 스프링 컨테이너에서 찾아서 넣어준다.

• 이렇게 객체 의존관계를 외부에서 넣어주는 것을 DI(Dependency Injection), 의존성 주입이라고 한다.

싱글톤(Singleton)

•  인스턴스를 오직 한 개만 생성할 수 있는 클래스를 싱글톤 이라고 한다.

•  객체 생성 요청이 여러번 발생하더라도 새롭게 메모리를 할당하여 인스턴스를 만드는 것이 아닌,
    기존에 생성되어 있던 인스턴스를 참조한다.

•  사용 예시 : Scheduling 처리 객체 등

•  장점 : 불필요한 메모리 사용을 줄일 수 있다

•  단점 : 이를 사용하는 클라이언트를 테스트하기 어려워 질 수 있다.

    ◦  싱글톤 인스턴스를 가짜(mock) 구현으로 대체할 수 없기 때문.


싱글톤을 만드는 두가지 방법

•  공통점 : 생성자는 private으로, 인스턴스에 접근할 수 있는 유일한 수단 = public static 멤버

1) public static 멤버를 final 필드로 선언

public class Elvis {
		**public** static **final** Elvis INSTANCE = new Elvis();
		private Elvis() { ... }
}

•  private Elvis 생성자는 Elvis.INSTANCE 를 생성할 때(new Elvis) 딱 한 번 호출됨

•  다른 클래스에서 참조할 수 없는 생성자(private) 이므로 Elvis 클래스가 가지는 인스턴스는 Elvis.INSTANCE 단 한 개 뿐임을 보장할 수 있다.

•  예외) 권한이 있는 클라이언트가 AccessibleObject.setAccessible(리플렉션 API)을 사용해 private 생성자를 호출하는 경우

   ◦  리플렉션 : 개발자가 클래스의 구조를 확인하거나, 값/메소드를 호출해야 할 때 사용됨 (런타임 동작 검사 및 수정에 주로 이용된다)

   ◦  setAccessible : 필드나 메서드의 접근제어 지시자에 의한 제어를 변경하는 메서드

Elvis.setAccessible(true); // 이제 외부에서 private Elvis() 접근가능!

•  장점) 해당 클래스가 싱글톤임이 명백하게 드러나며 간결하다.

   ◦  public static 필드가 final 이므로 절대 다른 객체를 받을 수 없기 때문

 

2) 정적 팩토리 메서드를 public static 멤버로 제공

public class Elvis {
		**private** static **final** Elvis INSTANCE = new Elvis();
		private Elvis() { ... }
		**public static Elvis getInstance() { return INSTANCE; }**
}

•  Elvis.getInstance : 항상 같은 객체의 참조를 반환하므로 제2의 Elvis 인스턴스는 생성될 수 없음.

•  장점 1) API를 바꾸지 않고도 싱글톤이 아니게 변경 가능 (스레드별로 다른 인스턴스를 넘겨주는 등)

•  장점 2) 정적 팩토리 → 제네릭 싱글톤 팩토리 로 변경 가능

•  장점 3) 정적 팩토리의 메서드 참조를 공급자(supplier)로 사용 가능

   ◦  Elvis::getInstance 를 Supplier<Elvis>로 사용하는 식


싱글톤 클래스의 직렬화

•  직렬화란? : 자바 시스템 내부에서 사용되는 객체 또는 데이터들을 외부의 자바 시스템에서도 사용할 수 있도록
                       바이트(byte) 형태로 데이터 변환하는 기술

•  역직렬화 : 바이트로 변환된 데이터를 다시 객체로 변환하는 기술 (JVM)

•  모든 객체 필드를 일시적(transient)이라고 선언하고 readResolve 메서드를 제공해야 함

   ◦  안그러면 직렬화된 인스턴스를 역직렬화할 때 마다 새로운 인스턴스가 만들어진다.

       -  예 ) 새로운 인스턴스를 생성하는 것 = 가짜 Elvis를 생성하는 것

   ◦  역직렬화 과정에서 만들어진 인스턴스 대신 기존에 생성된 싱글톤 인스턴스를 반환해주는 역할

public class Elvis implements Serializable {
	private static final Elvis INSTANCE = new Elvis();
	private Elvis() { ...	}
	public static Elvis getInstance() { return INSTANCE; }

	**private Object readResolve() { return INSTANCE;	}**
}

싱글톤을 만드는 세번째 방법 : 원소가 한개인 Enum 클래스 사용하기

public enum Elvis { INSTANCE; }

•  코드가 매우 간결하고! 또 더 쉽게 직렬화가 가능하다.

•  복잡한 직렬화 상황 혹은 Reflection에 의해 제 2의 인스턴스가 생기는 일을 방지한다.

   ◦  enum은 기본적으로 serializable 하기 때문에 serializable interface 를 따로 구현할 필요가 없다. 따라서 역직렬화 시에 runtime 내부에 존재하는 enum class, 즉 동일한 값을 참조한다.

   ◦  enum class는 외부에서 액세스 할 수 있는 생성자 자체가 없으므로 reflection에 면역! (enum class 생성자 = Sole Constructor / 컴파일러에서 사용하는 것으로 사용자가 직접 호출 불가)

   ◦  따라서 대부분의 상황에서 Enum 선언이 싱글톤을 만드는 가장 좋은 방법이다.

       -  단, 만들고자 하는 싱글톤이 Enum 외의 클래스를 상속해야 한다면 이 방법은 사용할 수 없다.


참고자료

 

싱글톤(Singleton) 패턴이란?

이번 글에서는 디자인 패턴의 종류 중 하나인 싱글톤 패턴에 대해 알아보자. 싱글톤 패턴이 무엇인지, 패턴 구현 시 주의할 점은 무엇인지에 대해 알아보는 것만으로도 많은 도움이 될 것이라

tecoble.techcourse.co.kr

 

[Java] Enum의 사용법

안녕하세요. 지난 시간엔 EnumClass가 무엇이고 어떤 장점들이 있는지 알아보았습니다. 2017/06/27 - [Java] - [Java] enum 이란? (enum 개념익히기) 이번 시간은 Enum 사용방법을 더 알아보면서 Enum에 대한 이.

limkydev.tistory.com

 

[Java & Kotlin] enum class가 완벽한 싱글톤이라 불리는 이유

싱글톤 패턴(Singleton Pattern)이란? 싱글톤은 애플리케이션 상 특정 클래스가 최초 한 번만 메모리를 할당하고 그 메모리에 인스턴스를 만들어 사용하는 디자인 패턴을 의미한다. 객체 생성 요청이

dataportal.kr

 

[java] enum 의 serialize 에 대한 이야기

- enum 은 기본적으로 serializable 하다. - enum 의 serialization 은 다른 serialization 과 조금 다르다. enum 의 serialize 결과는 constant 의 이름뿐이다. enum serialize 시 ObjectOutputStream 에서는 'n..

aroundck.tistory.com