java on 오늘도 개발을 한다.

[Java] Exception 알아보기

Wed, 26 Jun 2024 16:54:30 +0900

서론

CS 스터디에서 6월 19일 발표한 Exception에 대해 정리한 문서를 블로그에 공유하고자 한다.

Java에서, Exception이란?

Exception 이란, Java 프로그램 실행 도중 발생하는 이벤트 로, 정상적인 명령 흐름을 방해합니다.

예외 처리 흐름

어떠한 메서드 내에서 오류가 발생하면, 메서드는 예외 객체(Exception Object)를 생성해 런타임 시스템에게 넘깁니다.
이때, 이처럼 예외 객체를 생성해 런타임 시스템에 전달하는 것을 예외를 던진다(Throwing an Exception)라고 합니다.

예외 객체(Exception Object) : 발생한 오류의 유형, 발생 당시 프로그램의 상태와 같은 오류에 대한 정보를 포함하는 객체입니다.

메서드가 예외를 던지게 되면, 런타임 시스템은 이를 처리해줄 수 있는 무언가를 찾으려 합니다. 여기서 말하는 ‘무언가’는, 오류가 발생한 메서드에 도달하기 위해 호출된 메서드들이 정렬된 리스트를 이루고 있는데 이를 호출 스택(Call Stack)이라고 합니다.

런타임 시스템은 호출 스택에서 현재 발생한 예외를 처리할 수 있는 코드 블록이 포함되어있는 메서드를 찾습니다. 이러한 코드 블록을 예외 처리기(Exception Handler)라고 합니다.
이러한 탐색은 오류가 발생한 메서드부터 메서드가 호출된 역순으로 호출 스택을 훑으며 진행됩니다.
이때 적절한 처리기 를 찾게되면 런타임 시스템은 예외를 처리기에 전달하게 되고, 예외 처리기는 예외 객체의 유형이 처리기가 처리할 수 있는 유형과 일치하는 경우 적절한 처리기 로 간주됩니다.
만약 런타임 시스템이 적절한 예외 처리기를 찾지 못한채, 호출 스택의 모든 메서드들을 탐색했다면 런타임 시스템(과 프로그램)이 종료되게 됩니다.

Exception의 종류

Exception은 크게 Checked Exception, Unchecked Exception, Error 세가지로 구분됩니다.
Error, Runtime Exception 및 이들의 하위 클래스들을 제외한 모든 Exception은 Checked Exception 입니다.

Checked Exception

Checked Exception이란, 잘 작성된 Java 애플리케이션이라면 예상할 수 있어야 하고 복구해야 하는 예외를 말합니다.
예를 들어, 사용자에게 파일 이름을 입력 받고 이를 java.io.FileReader를 통해서 여는 애플리케이션이 있다고 가정합시다. 이때, 사용자가 존재하는 파일의 이름을 입력할 수도 있지만, 존재하지 않는 파일의 이름을 입력할 수도 있습니다. 이럴 경우 java.io.FileNotFoundException이 발생하게 됩니다.
이때 잘 작성된 애플리케이션이라면, 위 처럼 충분히 예상 가능한 예외 케이스에 대해 포착하고, 사용자의 실수를 알린 뒤 파일 이름을 다시 입력해달라는 메시지를 표시할 것입니다.
Checked Exception의 경우 try-catch 절을 이용해 예외를 처리 하거나, throws 절을 이용해 예외를 던져야 합니다. 그렇지 않을 경우 코드가 컴파일되지 않습니다.

Unchecked Exception

Runtime Exception

Runtime Exception이란, 애플리케이션 내부에 존재하지만 일반적으로 예상하거나 복구할 수 없는 예외를 말합니다.
일반적으로 논리 오류나 부적절한 API 사용과 같은 프로그래밍 버그를 말합니다.
Runtime Exception의 경우 Checked Exception과 달리, catch 또는 throws절에 의해 처리되거나 던져져지지 않아도 코드가 정상적으로 컴파일 됩니다.

Error

Error란, 애플리케이션 외부에서 발생하는 예외를 말하며, 애플리케이션이 일반적으로 예상하거나 복구할 수 없습니다.
예를 들어, 사용자가 입력한 파일을 정상적으로 열었지만, 하드웨어 또는 OS가 오작동해 파일을 읽을 수 없는 경우 java.io.IOError가 발생하게 됩니다.
이때 애플리케이션은 이를 포착하고 사용자에게 이를 알릴 수도 있지만, stack trace를 출력하고 프로그램을 종료하는 것 역시 합리적일 수 있습니다.
Error 역시 Checked Exception과 달리, catch 또는 throws절에 의해 처리되거나 던져져지지 않아도 코드가 정상적으로 컴파일 됩니다.

Exception 방식의 장점

오류 처리 코드와 메인 로직 코드의 분리

기존의 프로그래밍 방식에서는 메인 로직 코드와 오류 감지 및 처리 코드가 혼재해있어 코드의 가독성과 유지보수성이 떨어집니다.
반면 Exception 방식을 채용할 경우, 오류 처리와 관련된 세부 사항을 메인 로직 코드와 분리할 수 있습니다.

예시

기존의 방식이라면, 아래 코드처럼 메인 로직 중간중간에 오류를 감지하고 처리하는 코드가 존재하게 됩니다.

errorCodeType readFile {
    initialize errorCode = 0;
    
    open the file;
    if (theFileIsOpen) {
        determine the length of the file;
        if (gotTheFileLength) {
            allocate that much memory;
            if (gotEnoughMemory) {
                read the file into memory;
                if (readFailed) {
                    errorCode = -1;
                }
            } else {
                errorCode = -2;
            }
        } else {
            errorCode = -3;
        }
        close the file;
        if (theFileDidntClose && errorCode == 0) {
            errorCode = -4;
        } else {
            errorCode = errorCode and -4;
        }
    } else {
        errorCode = -5;
    }
    return errorCode;
}

반면 Exception 방식을 채용할 경우, 아래처럼 오류 감지 및 처리 코드가 정리되어 가독성이 높고 유지보수성이 높은 코드를 작성할 수 있게 됩니다.

readFile {
    try {
        open the file;
        determine its size;
        allocate that much memory;
        read the file into memory;
        close the file;
    } catch (fileOpenFailed) {
       doSomething;
    } catch (sizeDeterminationFailed) {
        doSomething;
    } catch (memoryAllocationFailed) {
        doSomething;
    } catch (readFailed) {
        doSomething;
    } catch (fileCloseFailed) {
        doSomething;
    }
}

오류를 호출 스택으로 전파할 수 있음

오류를 호출 스택에 있는 다른 메서드로 전파할 수 있어, 오류에 대해 관심이 있는 메서드만 오류 감지에 대해 신경쓰도록 코드를 작성할 수 있습니다.
따라서, 오류 처리에 관심이 없는 메서드는 그저 호출 스택 위로 예외를 던지기만하면 됩니다.

예시

예시로, method1 -> method2 -> method3 -> readFile 순서대로 함수를 호출한다고 가정하겠습니다. 의사 코드로 이를 표현하면 다음과 같습니다.

method1 {
    call method2;
}

method2 {
    call method3;
}

method3 {
    call readFile;
}

또한, 오류 처리에 대해서는 오직 method1만 관심이 있다고 가정하겠습니다.
기존의 오류 알림 기법이었다면 다음 의사코드처럼 return 문을 통해 발생한 오류를 전파했을 것입니다.

method1 {
    errorCodeType error;
    error = call method2;
    if (error)
        doErrorProcessing;
    else
        proceed;
}

errorCodeType method2 {
    errorCodeType error;
    error = call method3;
    if (error)
		// 에러가 발생한 경우, 호출 스택 상위의 메서드(method1)로 error 반환
        return error;
    else
        proceed;
}

errorCodeType method3 {
    errorCodeType error;
    error = call readFile;
    if (error) 
		// 에러가 발생한 경우, 호출 스택 상위의 메서드(method2)로 error 반환
        return error;
    else
        proceed;
}

하지만 Exception 방식의 경우 method2, 3에서 발생한 예외를 단순히 던져주기만 하면 됩니다.

method1 {
    try {
        call method2;
    } catch (exception e) {
        doErrorProcessing;
    }
}

method2 throws exception {
    call method3;
}

method3 throws exception {
    call readFile;
}

오류 타입의 그룹화 및 구분

Java 프로그램에서 던져지는 모든 예외는 객체이기 때문에, 클래스 계층 구조상 예외를 그룹화하거나 분류할 수 있게 됩니다.

다만, 대부분의 상황에서는 예외 처리기가 가능한 구체적인 예외를 처리하는 것이 좋습니다.
- 최선의 복구 전략을 결정하는데 있어 어떤 유형의 예외가 발생했는지 파악하는 것이 중요하기 때문입니다.

예시

예시로 Java의 I/O 작업 관련 예외의 부모인 IOException과 그 하위 클래스인 FileNotFoundException을 들어보겠습니다.
만약 파일을 찾을 수 없다는 예외만 처리하고 싶다면 catch문에서 FileNotFoundException만 명시하면 됩니다. (FileNotFoundException은 하위 클래스가 없습니다.)

catch (FileNotFoundException e) {
    ...
}

반면, I/O 작업과 관련된 예외 전체를 묶어 처리하고 싶다면 catch문에서 IOException을 명시하면 됩니다.

catch (IOException e) {
    ...
}

예외처리를 하는 세가지 방법

흔히 Java에서 예외를 처리하는 방법은 try-catch문을 이용한 예외복구, throws절을 이용한 예외회피, throw문을 이용한 예외전환 세가지 방법이 있다고 알려져 있습니다.

try-catch

try {

} catch (ExceptionType name) {

} catch (ExceptionType2 name) {

}

try-catch, 추가로 finally 문을 사용해 현재 메서드 내에서 예외를 처리하는 방법입니다.

try

먼저 예외가 발생할 수 있는 코드를 try 블록으로 묶고, try 블록 내부에서 발생 가능한 예외를 처리하는 예외 처리기가 존재하는 catch 블록을 연결하는 형태로 구현합니다.
이때, 예외가 발생할 수 있는 각 코드를 각각의 try-catch 문으로 묶을 수도 있고, 모든 코드를 하나의 try-catch 블록으로 묶어 처리할 수도 있습니다.

catch

각 catch 블록은 인자로 받는 예외 타입을 처리하는 예외 처리기로, 이때 예외 타입은 Throwable클래스의 하위 클래스여야 합니다.
런타임 시스템은 예외 처리기가 호출 스택에서 던져진 예외 타입과 일치하는 첫 번째 핸들러일 때, 예외 처리기를 호출합니다.
이때 예외 처리기 내부에서는 단순히 오류 메시지를 출력하거나 프로그램을 중지하는 것 외에도 다양한 작업을 수행할 수 있습니다.
오류를 복구하거나, 사용자에게 결정을 내리도록 메시지를 표시하거나, 상위 수준의 예외 처리기로 오류를 전파할 수도 있습니다.

Union catch 절

추가로, Java 7 이상에서는 | 키워드를 통해 하나의 catch 블록이 둘 이상의 예외 타입을 처리할 수 있습니다.

catch ( IOException | SQLException ex) {
    logger.log(ex);
    throw ex;
}

참고로 catch 블록이 둘 이상의 예외 타입을 처리하는 경우, 해당 catch절의 매개변수는 암시적으로 final로 여겨집니다. 즉, catch 블록 내에서 해당 매개변수에 어떠한 값도 할당할 수 없습니다.

finally

...
finally {
    if (out != null) { 
        System.out.println("Closing PrintWriter");
        out.close(); 
    } else { 
        System.out.println("PrintWriter not open");
    } 
    if (f != null) {
	    System.out.println("Closing FileWriter");
	    f.close();
	}	
}

finally블록은 try 블록을 탈출할 때, 항상 실행되는 블록입니다.
따라서 예상치 못한 예외가 발생해도, 항상 실행됩니다. 이러한 특징 때문에 프로그래머가 실수로 return, continue,break 블록을 통해 클린업 코드가 무시되는 것을 방지할 때도 유용합니다.

클린업 코드: 사용한 자원 등을 정리하는 코드

try-with-resources

try (FileReader fr = new FileReader(path);
	 BufferedReader br = new BufferedReader(fr)) {
	return br.readLine();
}

try-with-resources 문이란, 하나 이상의 자원을 선언하는 try 문을 말합니다.
이때 자원은, 프로그램이 완료된 후 닫아야(close)하는 객체를 말합니다.
try-with-resources 문에는 java.lang.AutoCloseable을 구현하는 모든 객체(java.io.Closeable을 구현하는 객체 포함)를 자원으로 사용할 수 있습니다.

참고로 Closeable 인터페이스는 AutoCloseable 인터페이스를 상속합니다.
추가로, AutoCloseable의 close()는 Exception 타입의 예외를 던지지만, Closeable 인터페이스는 IOException 타입의 예외를 던집니다.

선언된 자원들은 try문이 정상적으로 완료 되었는지 또는 예외가 발생했는지에 관계 없이 항상 닫히게 됩니다.
try-with-resources문은 finally 블록을 통해서 여러 자원을 닫을 때 예외가 발생할 경우, 아직 닫지 못한 자원이 메모리 누수를 발생시킬 수 있는 것과 달리, 항상 자원을 닫음을 보장하기 때문에 try-with-resources문을 사용하는 것이 권장됩니다.
추가로, try 블록과 try-with-resources 문 모두에서 예외가 발생할 경우, try 블록에서 발생한 예외만 던지고, try-with-resources 문에서 발생한 예외는 억제됩니다.

이렇게 억제된 예외는 try 블록에서 발생한 예외의 Throwable.getSuppressed() 메서드를 통해 찾을 수 있습니다.

또한 자원의 close 메서드는 생성 순서의 반대 순서 로 호출됩니다.
그리고 try-with-resources문 역시 catch 블록과 finally 블록을 연결할 수 있는데, 이들은 모두 try문에서 선언된 자원이 닫힌 후 실행되게 됩니다.

throws

public void writeList() throws IOException, IndexOutOfBoundsException { ... }

위처럼 코드 내에서 발생할 수 있는 예외를 해당 코드에서 직접 처리하도록 하는게 적절할 수도 있지만, 호출 스택의 상위 메서드가 예외를 처리하도록 하는 것이 더 좋을 수도 있습니다.
이때 throws절을 사용해 예외를 회피할 수 있습니다.
throws절에는 해당 메서드 내에서 발생할 수 있는 예외를 하나 이상 기입할 수 있습니다. 이때, 둘 이상의 예외는 쉼표를 통해 구분해 기입합니다.
참고로 Unchecked Exception의 경우 Checked Exception과 달리 throws절에 꼭 포함시키지 않아도 됩니다.

throw

try {
	...
} catch (IOException e) {
    throw new SampleException("Other IOException", e);
}

어느 곳에서 하나의 예외가 발생한 경우, 애플리케이션에서 종종 다른 예외를 던저 이에 응답하는 경우가 있습니다.
즉 하나의 예외가 다른 예외를 유발하는 것인데, 이를 연쇄 예외(Chained Exception)라고 합니다. 이는 주로 Throwable의 생성자인 Throwable(String, Throwable), Throwable(Throwable)를 활용해 이뤄집니다.
또한 Throwable의 getCause() 메서드를 통해 현재 예외를 발생시킨 예외를 얻거나, initCause(Throwable) 메서드를 통해 현재 예외의 원인을 설정할 수도 있습니다.

예외처리가 성능에 끼치는 영향은 어느정도일까?

Benchmark	Mode	Cnt	Score	Error	Units
ExceptionBenchmark.createExceptionWithoutThrowingIt	avgt	10	16.605	± 0.988	ms/op
ExceptionBenchmark.doNotThrowException	avgt	10	0.047	± 0.006	ms/op
ExceptionBenchmark.throwAndCatchException	avgt	10	16.449	± 0.304	ms/op
ExceptionBenchmark.throwExceptionWithoutAddingStackTrace	avgt	10	1.185	± 4.991	ms/op
ExceptionBenchmark.throwExceptionAndUnwindStackTrace	avgt	10	326.560	± 0.015	ms/op

Performance Effects of Exceptions in Java | Baeldung의 벤치마크 결과를 보면, 예외를 발생시키고 이를 try-catch 블록으로 처리하는 메서드는 예외가 발생하지 않는 메서드에 비해 수백 배 느리게 실행됩니다. 심지어 단지 예외를 생성하기만 하는 메서드 역시 수 백배 느립니다.
하지만 예외를 발생시키고, 이를 try-catch 블록으로 처리하는 메서드에서 Stack Trace에 해당 예외를 추가하지 않도록 했더니 시간을 수 백배 단축할 수 있었습니다.
게다가 발생한 예외의 getStackTrace() 메서드를 호출해 StackTrace를 Unwinding, 즉 현재 메서드 부터 호출 스택의 메인 메서드 까지 되감아 올라갈 경우 실행 시간이 스무 배 증가했습니다.
이를 종합해 보면, Stack Trace에 예외를 추가하는데 상당한 성능 저하가 발생함을 알 수 있습니다. 특히, Stack Trace를 Unwinding하는 경우 성능 저하는 더욱 심해집니다.
따라서 예외 처리에 따른 성능 저하를 방지하기 위해서는, 최대한 적재적소에만 예외 처리문을 사용하는 것이 좋습니다. 즉, 예외 처리문을 가능한 적게 사용하는 것이 좋습니다.

참고

[Java] synchronized 알아보기

Mon, 04 Mar 2024 23:19:16 +0900

서론

CS 스터디에서 3월 6일 발표한 synchronized에 대해 정리한 문서를 블로그에 공유하고자 한다.

`synchronized` 키워드란?

멀티 스레드 환경에서 Java 언어가 공유 자원에 대한 동기화 처리를 위해 사용되는 관용구(idiom)입니다. 이 키워드를 사용해 개발자는 간단하게 경쟁 조건(Race Condition) 을 피할 수 있습니다.
Synchronized 키워드를 사용하게 되면 Java는 내부적으로 모니터(monitor)(모니터 락(monitor lock) 또는 내재적 락(intrinsic lock)이라고도 불림)을 사용해 동기화를 처리합니다.
모니터는 동기화에 필요한 ‘객체 상태에 대한 배타적 액세스 강제’, ‘가시성(visibility)에 필수적인 발생-전(happen-before) 관계 설정’ 과 같은 작업을 수행하는 역할을 합니다.

가시성: 동일한 synchronized 블록에 진입하는 다음 스레드는 이전 스레드가 본 것과 같은 변수 값들을 보게 됩니다.
발생-전(happen-before): 명령어의 순서 변경을 통해 작업 간의 순서 및 가시성을 보장하는 것을 말합니다. 이를 통해 한 스레드에서 변경된 내용이 다른 스레드에 표시될 수 있도록 보장합니다.

모든 객체는 관련된 내재적 락이 존재하고, 관례에 따라 객체의 필드에 독점적이고 일관적이게 접근해야하는 스레드는 ‘내재적 락’을 얻고 접근 후 ‘내재적 락’을 해제해야 합니다.
이러한 모니터는 객체에 바인딩 되므로, 동일한 객체의 모든 synchronized 블록은 동시에 한 스레드만 실행할 수 있습니다.
synchronized 키워드는 메서드 앞에 붙이거나 코드 블럭 중간에 사용할 수 있습니다.

키워드 위치에 따른 의미

`인스턴스 메서드`

public synchronized void synchronisedCalculate() {
    setSum(getSum() + 1);
}

메서드 선언 앞에 synchronized 키워드를 붙임으로써 해당 메서드가 동기화 처리 되도록 합니다.
메서드를 소유한 인스턴스에 의해 동기화되므로, 한 인스턴스 당 하나의 스레드만 해당 메서드를 실행할 수 있습니다.

`정적 메서드`

 public static synchronized void syncStaticCalculate() {
     staticSum = staticSum + 1;
 }

정적 메서드 앞에 synchronized 키워드를 붙임으로써 해당 메서드가 동기화 처리 되도록 합니다.
해당 메서드를 소유한 클래스의 Class 객체에 의해 동기화됩니다. 클래스 별로 JVM 당 하나의 Class 객체만 존재하므로 인스턴스 갯수에 상관없이 하나의 스레드만 해당 메서드를 실행할 수 있습니다.

`코드 블록`

// 인스턴스 메서드 내 코드 블록 synchronized
public void performSynchronisedTask() {
    synchronized (this) {
        setCount(getCount()+1);
    }
}

메서드 중간에 synchronized (obj) 키워드를 사용하므로써 코드 일부를 동기화 할 수 있습니다.
synchronized에 매개변수로 전달되는 객체는 모니터 객체로, 블록 내부의 코드는 해당 객체에서 동기화됩니다. 따라서, 모니터 객체 당 하나의 스레드만 해당 코드 블록 내의 작업을 실행할 수 있습니다.
정적 메서드의 경우, 매개변수로 전달되는 Class 객체에 의해 동기화 됩니다.

// 정적 메서드 내 코드 블록 synchronized
public static void performStaticSyncTask(){
    synchronized (SynchronisedBlocks.class) {
        setStaticCount(getStaticCount() + 1);
    }
}

`재진입성(Reentrancy)`

스레드가 락을 소유하고 있는 동안, 해당 락을 다시 획득할 수 있습니다.
이렇게 한 스레드가 같은 락을 두 번 이상 획득할 수 있도록 허용하게 되면 재진입 동기화(reentrant synchronization)가 가능합니다.

Object lock = new Object();
synchronized (lock) {
    System.out.println("First time acquiring it");

    synchronized (lock) {
        System.out.println("Entering again");

         synchronized (lock) {
             System.out.println("And again");
         }
    }
}

즉, synchronized 코드가 직접/간접적으로 synchronized 코드가 포함된 메서드를 호출하고, 두 코드가 같은 락을 사용하는 상황이 가능하게 됩니다.
이러한 재진입 동기화 없이는 synchronized 코드는 스레드 스스로를 차단하지 않도록 추가적인 예방 조치를 취해야합니다.

효율적인 코드 작성 측면에서, `synchronized`는 좋은 키워드일까?

synchronized 키워드는 공유 자원에 대한 여러 스레드의 접근을 제어해 간편하게 동기화 처리가 가능한 유용한 키워드지만, 아래와 같은 단점이 존재합니다.

성능 저하

락을 사용해 한 번에 한 스레드만 코드 블록(또는 메서드 전체)에 접근 가능하므로 다른 스레드들은 해당 코드 블록의 모니터가 필요한 다른 메서드들을 실행하지 못하고 대기해야 합니다. 따라서 멀티-스레드 환경의 이점인 동시성을 잃습니다.
또한, synchronized 코드 실행을 기다리는 동안 블록된 스레드는 중단(interrupt)될 수 없습니다.

데드락

락을 기반으로 동기화를 처리하므로, 둘 이상의 스레드가 락을 획득하고 서로의 락을 얻기위해 무한히 대기하는 데드락이 발생할 수 있습니다.

예상치 못한대로 동작할 수 있음

락을 기반으로 하므로, 락의 기준으로 설정되는 객체에 따라 코드가 예상한대로 동작하지 않을 수 있습니다.
예를 들어 인스턴스 메서드 M1, M2에 synchronized 키워드를 사용했고, 스레드 A,B 가 동작중인 상황이라면 스레드 A가 M1 메서드를 수행하는 동안, B는 M1 메서드 뿐만 아니라 M2 메서드에도 진입할 수 없습니다.

이는 synchronized 인스턴스 메서드 의 락이 인스턴스를 기준으로 하기 때문에 동일한 인스턴스에 대해서 메서드들은 이미 한 synchronized 메서드가 실행 중이라면, 다른 synchronized 메서드 역시 수행할 수 없습니다.

`synchronized`이외의 다른 동기화 기법

Java에서는 synchronized 키워드 이외에도 동기화를 처리할 수 있는 방법들을 제공하고 있습니다.

`락 객체(Lock Object)`

락 객체는 기존의 synchronized 블록에서 사용하던 모니터와 유사하지만 보다 정교한 형태입니다.
모니터와 마찬가지로 한 번에 한 스레드만 Lock 객체를 소유할 수 있으며, Lock 객체는 연결된 Condition 객체를 통해 대기/알림(wait/notify) 메커니즘도 지원합니다.

대기/알림(wait/notify): 스레드가 처리할 수 있는 상태면 notify()를 통해 Runnable 상태로, 그렇지 않다면 wait()을 통해 대기 상태로 변경하는 방식.

락 객체를 사용하면, 기존의 모니터와 달리 락을 획득할 수 없는 경우 다른행동을 할 수 있다는 장점이 있습니다.

...
static class Friend {
	private final Lock lock = new ReentrantLock();
	...
	// Lock을 얻고자 시도하는 함수
	public boolean impendingBow(Friend bower) {
		Boolean myLock = false;
		Boolean yourLock = false;
		try {
      // 락 획득 시도
			myLock = lock.tryLock();
			yourLock = bower.lock.tryLock();
		} finally {
			if (! (myLock && yourLock)) {
				if (myLock) {
					lock.unlock();
				}
				if (yourLock) {
					bower.lock.unlock();
				}
			}
		}
		return myLock && yourLock;
	}
	// 메인 행동 함수
	public void bow(Friend bower) {
		if (impendingBow(bower)) {
      // 락 획득에 성공한 경우
			try {
				System.out.format("%s: %s has"
					+ " bowed to me!%n", 
					this.name, bower.getName());
				bower.bowBack(this);
			} finally {
				lock.unlock();
				bower.lock.unlock();
			}
		} else {
      // 락 획득에 실패한 경우
			System.out.format("%s: %s started"
				+ " to bow to me, but saw that"
				+ " I was already bowing to"
				+ " him.%n",
				this.name, bower.getName());
		}
	}

java.util.concurrent.locks 패키지에 인터페이스인 Lock은 물론 ReentrantLock와 같은 구현체도 존재합니다.

`Volatile`

공유 메모리 환경에서 발생할 수 있는 캐시 일관성 문제를 해결해주는 키워드입니다. 변수에 해당 키워드를 달게되면, 변수에 대한 모든 수정이 즉시 다른 스레드에게 전파됩니다. 이는 Volatile 키워드가 달린 변수는 CPU 캐시가 아닌 메인 메모리에서 읽고 쓰기 때문에 가능합니다.

private volatile static int number;

synchronized 코드 블록과 달리, 한 번에 여러 스레드가 코드 블록을 실행해도 변수의 가시성을 보장할 수 있습니다.

`원자 변수(Atomic variable)`

java.util.concurrent.atomic 패키지 내에 단일 변수에 대한 원자 연산을 지원하는 클래스들이 정의되어 있습니다.
AtomicBoolean, AtomicInteger 등 원시 타입에 대응되는 원자 변수는 물론, AtomicReference 와 같이 객체에 대응되는 원자 변수도 존재합니다.
클래스들은 volatile 변수에 대한 읽기/쓰기처럼 동작하는 get()/set()를 갖고 있습니다.
따라서, set()은 같은 변수에 대한 모든 이후의 get() 호출에 대해 발생-전 관계(happens-before Relationship) 를 갖습니다.

import java.util.concurrent.atomic.AtomicInteger;

class AtomicCounter {
    private AtomicInteger c = new AtomicInteger(0);

    public void increment() {
		// Atomically increments by one the current value.
        c.incrementAndGet();
    }

    public void decrement() {
		// Atomically decrements by one the current value.
        c.decrementAndGet();
    }

    public int value() {
        return c.get();
    }

}

ThreadLocal이란?

java.lang 패키지에 존재하는 클래스로써, 이를 사용하면 각 스레드 별로 스스로만 접근할 수 있는 데이터를 저장할 수 있습니다.

// 먼저, 값을 저장할 ThreadLocal 인스턴스를 생성합니다.
ThreadLocal<타입> threadLocalValue = new ThreadLocal<>();

// get(), set() 메서드를 통해 값을 읽고, 쓸 수 있습니다.
threadLocalValue.set(1);
Integer result = threadLocalValue.get();

// remove() 메서드를 통해 값을 지울 수 있습니다.
threadLocalValue.remove();

주의사항

이를 ThreadPool과 함께 사용 할 경우, ThreadLocal의 값을 지우지 않고 현재 스레드를 풀에 반납했다 다시 사용하게 되면 이전에 ThreadLocal에 저장한 값이 남아있게 됩니다.
이를 주의해서 사용할 필요가 있습니다.

참고 문서

[Spring] IoC와 DI 알아보기

Tue, 27 Feb 2024 01:55:34 +0900

서론

CS 스터디에서 2월 27일에 발표 예정인 IoC와 DI에 대해 정리한 문서를 블로그에 공유하고자 한다.

IoC와 DI란?

IoC (Inversion of Control, 제어의 역전)

제어의 역전 은 사용자가 작성한 코드가 제네릭 프레임워크로부터 제어의 흐름을 전달받는 디자인 패턴을 말합니다.
절차적 프로그래밍에선 사용자의 코드가 일반적인 작업을 위해 라이브러리를 호출하지만, 제어의 역전에선 프레임워크가 사용자의 코드를 호출하게 됩니다.
제어의 역전은 재사용 가능한 코드와 특정 문제를 위한 코드가 애플리케이션에서 함께 동작해도, 독립적으로 개발된다는 의미를 지닙니다.

예시
[기존의 방식]
애플리케이션의 메인 함수가 사용자에게 표시할 명령어들의 목록을 불러오기 위해 메뉴 라이브러리의 함수를 호출합니다.
이후, 사용자가 선택한 명령어를 해당 함수가 반환하고, 메인 함수가 그 값을 토대로 관련된 명령을 실행합니다.
[제어의 역전을 적용한 방식]
애플리케이션을 창 시스템, 메뉴, 마우스 제어와 같은 일반적인 동작 및 그래픽 요소를 알고 있는 프레임워크를 사용해 작성합니다.
해당 애플리케이션이 어떤 메뉴를 제공하고, 해당 메뉴는 어떤 코드 서브루틴을 수행하는지는 사용자가 작성한 코드에 따라 달라지게 됩니다.

Spring에서

Spring에선 이러한 IoC가 본래 의미보다, 애플리케이션 객체에 의해 사용되는 종속성의 구현체에 대한 제어 권한을 프레임워크에게 부여한다는 의미로 사용됩니다.

장점

작업의 실행과 구현의 분리

쉬워지는 구현체 전환(switch)

프로그램 모듈성 향상

테스트의 용이함

컴포넌트들을 격리하거나, 종속성들을 모의 객체로 대체할 수 있어 테스트를 더욱 쉽게 할 수 있습니다.

DI (Dependency Injection, 의존성 주입)

의존성 주입 은 어떤 객체나 함수가 필요로 하는 다른 객체나 함수를 내부에서 생성하는 것이 아닌, 외부에서 전달 받는 프로그래밍 기법입니다.
의존성 주입은 객체를 생성하고 사용하는데 있어 관심사(concern)를 분리하므로써 프로그램이 느슨한 결합(loosely coupled)을 갖도록 하는것을 목표로 합니다.
이러한 관심사 분리를 통해 특정 서비스를 사용하려는 객체나 함수는 해당 서비스가 어떻게 생성되는지 알지 못해도 된다는 것을 보장합니다.

Spring에서

의존성 주입(DI) 은 객체가 그들의 종속성을 정의하는 특수한 형태의 IoC입니다.
이러한 종속성 정의는 생성자 인수, 팩토리 메서드 인수, 인스턴스 내 속성(property)을 통해서만 정의됩니다. 이후 IoC 컨테이너 (BeanFactory, ApplicationContext 등)에 의해 빈이 생성될 때 이러한 의존성들이 주입됩니다.
이 과정은 근본적으로 클래스를 직접 생성하거나, 서비스 로케이터 패턴과 같은 기법을 사용해 종속성의 인스턴스화 및 위치 지정을 제어하는 빈의 반대라고 할 수 있습니다.

유형

Spring에서 의존성을 주입하는 방식으로는 생성자 기반 DI, 설정자 기반 DI, 필드 기반 DI 방식이 있습니다.
이중 생성자 기반 DI 방식이 권장되는데, NPE를 방지 할 수 있고 final 선언이 가능하기 때문입니다.

생성자 기반 DI를 사용하는 경우, 필수 의존성들이 세팅되어있지 않은 상황에선 빈을 생성조차 못하기 때문에 NPE이 발생하지 않지만, 나머지 두 방식은 null 상태가 가능하게 됩니다.
또한, 생성자 기반 DI 방식을 사용하면 필드를 final로 선언할 수 있어 불변 형태의 이점을 활용할 수 있습니다.

생성자 기반 DI (Constructor)

설정하고자 하는 의존성들을 인수로 받는 생성자를 호출해 의존성을 설정하는 방식입니다.
IoC 컨테이너는 인수들의 타입, index와 같은 attribute를 토대로 의존성을 주입합니다.

@Component
public class Water {
    private final TeaBag teaBag;

    public Water(TeaBag chamomile) {
        this.teaBag = chamomile;
    }
}

설정자 기반 DI (Setter)

no-args 생성자 또는 no-args 정적 팩토리 메서드를 통해 빈을 인스턴스화 한 후 설정자를 호출해 의존성을 설정하는 방식입니다.

@Component
public class Milk {
    private Cereal cereal;

    @Autowired
    public void setCereal(Cereal cereal) {
        this.cereal = cereal;
    }
}

필드 기반 DI (Field)

@Autowired 애너테이션으로 필드를 표시해 의존성을 주입하는 방식입니다. 객체를 생성하는 동안 빈을 주입할 생성자, 설정자가 없는 경우 IoC 컨테이너는 Reflection을 이용해 주입하게 됩니다.

Reflection을 사용하기 때문에 더 많은 비용이 들고, 종속성을 추가하기 쉽기 때문에 종속성을 늘릴 수록 단일 책임 원칙을 위배할 가능성이 커지므로 다른 방식에 비해 권장되지 않습니다.

@Component
public class Juice {
    @Autowired
    private Orange orange;
}

특정 기능을 하는 클래스가 하나인 경우 Bean 대신 구체 클래스를 사용해도 되지 않나?

구체 클래스를 직접 사용해도 되지만, 이러한 방식은 코드 자체를 변경하지 않으면 동작 방식을 변경할 수 없다 는 단점이 존재합니다.
그리고 이러한 단점은 아래와 같은 단점들을 유도합니다.
만약 Bean을 사용하게 된다면, 프로그램의 결합도를 낮추고 코드 유연성을 높일 수 있으며 테스트가 더욱 용이해집니다.

결합도 증가

구체 클래스를 직접 사용하게 되면, 해당 클래스와 이를 사용하는 클래스 간 결합도가 높아지게 되고, 이는 코드의 변경을 힘들게 만듭니다.

유연성 감소

특정 구현에 직접적으로 의존하게 되면, 해당 구현을 변경 및 확장하는데 어려움을 겪게됩니다.

테스트의 어려움

구체 클래스를 직접 사용하게 되면 이를 모의 객체로 대체하기 어려워 테스트가 복잡해집니다.

Spring의 Bean 생성 주기

Bean의 생성 범위(`scope`) 공식 문서

빈 정의(bean definition)를 생성할 때 마다, 빈 정의에 정의된 클래스의 인스턴스를 생성하는 레시피를 함께 생성하게 됩니다.

빈 정의(bean definition): XML과 같은 configuration에 작성하는 bean의 metadata 입니다.
인스턴스를 만들어 낼 수 있는 레시피로 이를 활용해 하나에서 많게는 여러 개의 인스턴스를 생성할 수 있습니다.
빈 정의 안에는 생성된 객체에 연결된 다양한 종속성과 설정 값 뿐만 아니라 객체의 범위 역시 제어할 수 있습니다.
Spring의 경우 6개의 scope를 지원하며, 이 중 4개는 web-aware ApplicationContext를 사용하는 경우에만 사용할 수 있습니다. 또한, 커스텀 scope도 만들 수 있습니다.

Scope	Description
singleton	(Default) 빈 정의의 범위를 각 IoC 컨테이너의 단일 객체 인스턴스로 지정합니다. 해당 빈에 대한 모든 요청은 캐시된 동일한 객체를 반환합니다.
prototype	빈 정의의 범위를 원하는 수 만큼의 객체 인스턴스로 지정합니다. 즉 컨테이너에서 요청할 때 마다 다른 인스턴스를 반환합니다.
request	빈 정의의 범위를 단일 HTTP 요청 생명 주기로 지정합니다. 즉 각 HTTP 요청은 객체 인스턴스를 갖고 있습니다.
session	빈 정의의 범위를 HTTP 세션의 생명 주기로 지정합니다.
application	빈 정의의 범위를 `ServletContext` 의 생명 주기로 지정합니다.
websocket	빈 정의의 범위를 `Websocket`의 생명 주기로 지정합니다.

`singleton`

singleton으로 등록된 빈은 컨테이너가 단일 인스턴스로 생성해 관리하며, 해당 빈에 대한 모든 요청은 캐시된 동일한 객체를 반환합니다.
해당 객체에 대한 수정은 객체에 대한 다른 모든 참조에 영향을 줍니다.

XML

...
	<bean id="personSingleton" class="org.baeldung.scopes.Person" scope="singleton"/>

Annotation

...
@Bean
@Scope("singleton")
// 또는 @Scope(value = ConfigurableBeanFactory.SCOPE_SINGLETON)
public Person personSingleton() {
    return new Person();
}

`prototype`

prototype으로 등록된 빈은 컨테이너에서 해당 빈에 대한 요청이 들어올 때 마다 다른 인스턴스를 반환합니다.
다른 scope들과 달리, Spring은 prototype 빈의 전체 생명 주기를 관리하지 않습니다.
IoC 컨테이너는 prototype 객체를 인스턴스화 하고 의존성 주입한 뒤, 클라이언트에게 넘겨주고 더 이상 관리하지 않습니다.
따라서 초기화 생명 주기 콜백(init())은 scope에 관련 없이 모두 잘 동작하지만, 파괴 생명 주기 콜백(destroy())은 prototype 객체에서 호출되지 않습니다.

따라서 클라이언트 코드는 prototype 객체를 cleanup 하고 객체가 보유한 자원들을 해제하도록 해야 합니다.

XML

...
	<bean id="personPrototype" class="org.baeldung.scopes.Person" scope="prototype"/>

Annotation

@Bean
@Scope("prototype")
// 또는 @Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public Person personPrototype() {
    return new Person();
}

Bean의 Lifecycle

빈은 Spring IoC 컨테이너에 의해 관리됩니다.
IoC 컨테이너에 의해 빈이 인스턴스화 되고, 의존성이 주입되고, IoC 컨테이너가 종료된 후 빈은 파괴됩니다.

출처: https://www.geeksforgeeks.org/bean-life-cycle-in-java-spring/

이 과정에서 인스턴스화 이전, 파괴 이전 실행하고 싶은 코드가 있다면 생명주기 콜백 함수인 init(), destroy() 메서드 내부에 작성할 수 있습니다.
생명주기 콜백 함수를 작성하는 방법은 크게 3가지 방법이 존재합니다.

XML

XML파일의 빈 정의 내부에 사용할 사용자 정의 init() 및 destroy()를 등록하는 방식입니다. 이후 해당 XML 설정을 불러오는 IoC 컨테이너를 생성하고, 이를 close() 하게되면 init()/destroy() 함수가 호출되게 됩니다.

[예시]

<beans>
    <bean id="hw" class="beans.HelloWorld"
            init-method="init" destroy-method="destroy"/>
<!-- init-method/destroy-method에 사용자 정의 init()/destroy() 함수의 이름을 등록합니다 -->
</beans>

Interface

빈이 InitializingBean, DisposableBean을 상속하게 한 뒤, afterPropertiesSet(), destroy() 메서드를 재정의하도록 하는 방식입니다.
이렇게 하면 IoC 컨테이너는 빈의 생성 전, 컨테이너가 파괴된 후 해당 함수들을 호출하게 됩니다.
내부적으로 Spring 프레임워크는 BeanPostProcessor 의 구현체를 사용해 적절한 메서드들을 호출할 수 있는 콜백 인터페이스들을 처리합니다.
이 방식은 Spring 프레임워크와 코드를 불필요하게 결합시키는 측면이 있어, Spring에서도 XML을 사용하거나 애너테이션을 사용하는 방식을 권장합니다.

[예시]

public class AnotherExampleBean implements InitializingBean {
	@Override
	public void afterPropertiesSet() {
		// do some initialization work
	}
}

public class AnotherExampleBean implements DisposableBean {
	@Override
	public void destroy() {
		// do some destruction work (like releasing pooled connections)
	}
}

Annotation

빈으로 등록될 클래스의 메서드에 @PostConstruct, @PreDestroy 애너테이션을 달아주면 해당 빈이 인스턴스화되기 전, 컨테이너가 파괴된 후 해당 메서드들이 실행되게 됩니다.
이를 사용하기 위해선 CommonAnnotationBeanPostProcessor 빈을 등록하거나, Configuration XML 파일 내에서 <context:annotation-config/> 을 사용해야 합니다.

[예시]

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
 
// HelloWorld class
public class HelloWorld {
 
    // 빈이 인스턴스화 되었을 때 자동으로 실행되도록
	// 애너테이션을 달아줍니다.
    @PostConstruct
    public void init() throws Exception
    {
        System.out.println(
            "Bean HelloWorld has been "
            + "instantiated and I'm the "
            + "init() method");
    }
 
    // 스프링 컨테이너(=IoC 컨테이너)가 종료되면
	// 자동으로 실행되도록 애너테이션을 달아줍니다.
    @PreDestroy
    public void destroy() throws Exception
    {
        System.out.println(
            "Container has been closed "
            + "and I'm the destroy() method");
    }
}

참고문서

[Java] Reflection에 대해 알아보기

Sun, 18 Feb 2024 09:55:12 +0900

서론

CS 스터디에서 2월 6일에 발표한 Java의 Reflection에 대해 정리한 문서를 블로그에 공유하고자 한다.

Reflection이란? #Oracle 공식 문서

Reflection은 Java의 기능 중 하나로, 실행중인 Java 프로그램이 스스로를 검사하거나, 프로그램 내부 속성(클래스, 인터페이스, 필드 값 및 메서드)을 조작할 수 있게 해줍니다.
이는 컴파일 시간에 이름을 모르는 속성을 사용해야 할 때 특히 유용합니다.
또한, Reflection을 통해 새로운 객체를 인스턴스화 하거나, 메서드를 호출(invoke) 하고 필드 값을 얻거나 설정할 수 있습니다. 이러한 기능은 Java만의 특징 으로 Reflection이 처음 나온 1997년 당시에는 Pascal, C, C++와 같은 언어로 작성된 프로그램은 프로그램 내에서 정의된 함수에 대한 정보를 얻을 수 있는 방법이 없습니다.

다만 현대에는 C#, Javascript, Python, PHP와 같은 언어에서 Reflection을 지원하고 있습니다.

클래스/메서드 정보 가져오기

먼저 Reflection을 사용하기 위해선 JDK내에 있는 java.lang.reflect 패키지를 import 해야 합니다.
이후 클래스, 필드 값 및 메서드 정보를 얻고자하는 인스턴스에 대해 getClass()(Object) 메서드를 호출해 해당 객체의 런타임 클래스 표현을 얻어옵니다.

반환된 Class 타입의 객체는 클래스 정보에 접근하기 위한 메서드들을 제공합니다.

클래스 이름 가져오기

Class 클래스의 getSimpleName(), getName(), getCanonicalName() 메서드를 통해 인스턴스의 클래스 이름을 얻을 수 있습니다.
또한, Class.forName("정규화된 클래스 이름")을 통해 해당 클래스의 인스턴스를 만들 수 있습니다. 이때, 일치하는 클래스 이름이 없으면 ClassNotFoundException 이 발생합니다.

	Object abc = new ABC();
	Class<?> classInfo = abc.getClass();
	// 1. Class.getSimpleName() : 객체의 선언에 나타있는 기본 이름을 반환한다.
	// "ABC"
	System.out.println(classInfo.getSimpleName());
	// 2. Class.getName(), `Class.getCanonicalName()
	// "패키지 선언을 포함한" 정규화된 클래스 이름을 반환합니다.
	// "com.example.reflection.ABC"
	System.out.println(classInfo.getName());
	System.out.println(classInfo.getCanonicalName());

이외에도 필드 값의 이름을 가져오고프면 Field 클래스의 getName()을 호출하고, 메서드의 이름을 가져오고프면 Method 클래스의 getName()을 호출하면 된다.

클래스/필드/메서드 수식어(또는 지정자, 제한자) 가져오기

Class/Field/Method 클래스의 getModifiers() 메서드를 호출하면 해당 속성의 수식어 정보를 저장하고 있는 int 타입의 플래그 비트를 반환합니다.
이 플래그 비트는 java.lang.reflect.Modifier에서 제공하는 isPublic(), isAbstract()정적 메서드들을 통해 특정 수식어가 존재하는지 확인하는데 사용할 수 있습니다.

	Object abc = new ABC();
	Class<?> classInfo = abc.getClass();
	int abcMods = classInfo.getModifiers();
	// ABC 클래스가 public으로 선언되어 있는지 출력합니다.
	// "true"
	System.out.println(Modifier.isPublic(abcMods));

패키지 정보 가져오기

Class 클래스의 getPackage() 메서드를 호출하면 해당 클래스가 속한 패키지에 대한 정보들로 번들링된 Package 클래스 객체를 반환합니다.

	Object abc = new ABC();
	Class<?> classInfo = abc.getClass();
	Package pkgInfo = classInfo.getPackage();
	// ABC 클래스가 속한 패키지 이름을 출력합니다.
	// "com.example.reflection"
	System.out.println(pkgInfo.getName());

부모 클래스(Superclass) 정보 가져오기

Class 클래스의 getSuperclass() 메서드를 호출하면 해당 클래스의 부모 클래스 Class 객체를 얻을 수 있습니다.

라이브러리 또는 Java에 빌트인 되어있는 클래스의 경우, 객체의 부모 클래스를 알기 힘든 경우가 많은데 이런 경우 유용합니다.

	Object abc = new ABC();
	Class<?> classInfo = abc.getClass();
	Class<?> superClassInfo = classInfo.getSuperclass();
	// ABC 클래스의 부모인 Object 클래스를 출력합니다.
	// "Object"
	System.out.println(superClassInfo.getSimpleName());

클래스가 구현한 인터페이스 정보 가져오기

Class 클래스의 getInterfaces() 메서드를 호출하면 해당 클래스가 구현한 인터페이스 Class 객체의 배열을 얻을 수 있습니다.

이때, 해당 클래스가 implements 키워드를 통해 ‘구현할 것이라고 선언‘한 인터페이스들만 반환 됩니다. 즉, 부모 클래스들이 구현한 인터페이스들은 반환되지 않습니다.

	Object abc = new ABC();
	Class<?> classInfo = abc.getClass();
	// ABC 클래스의 경우 구현한 인터페이스가 없으므로
	// 아래 배열은 빈 배열 입니다.
	Class<?> abcInterfaceInfo[] = classInfo.getInterfaces();

생성자/메서드/필드 값 다루기

아래에서 getXXX/getDeclaredXXX이 혼용되어 나옵니다.
getXXX와 getDeclaredXXX의 차이: getXXX의 경우 해당 클래스는 물론 상속한 클래스, 구현한 인터페이스에서 선언된 것도 반환하지만, getDeclaredXXX의 경우 현재 클래스내에서 선언된 것만 반환합니다.
또한, getXXX의 경우 public으로 선언된 것만 반환하지만, getDeclaredXXX의 경우 클래스내에서 선언된 모든 요소들을 가져옵니다.

생성자 다루기

Class 클래스의 getConstructors() 메서드를 호출하면 해당 클래스의 생성자 정보들로 번들링 된 Constructor 클래스 배열을 반환합니다.

	Class<?> abcClass = Class.forName("com.example.reflection.ABC");
	Constructor<?>[] constructors = abcClass.getConstructors();

특정 생성자 가져오기

getConstructor()에 실제 선언되어있는 순서대로 인수들의 클래스(ex. int라면 int.class)를 파라미터로 넘겨주면 해당 시그니처를 갖는 생성자를 반환합니다.

만약 일치하는 시그니처를 갖는 생성자가 존재하지 않는다면 NoSuchMethodException이 발생합니다. 이는 Java에서 생성자 간 메서드 시그니처가 겹칠 수 없다는 점을 활용한 것 입니다.

class ABC {
	ABC(String Str, int Int) {
		...
	}
}
...
	Class<?> abcClass = Class.forName("com.example.reflection.ABC");
	// 첫 번째 인자로 String 값을 받고 두 번째 인자로 int 값을 받는 생성자를 반환합니다.
	Constructor<?> constructor = abcClass.getConstructor(String.class, int.class);

`Constructor` 클래스로 인스턴스 만들기

Constructor 클래스의 newInstance(매개변수) 메서드를 호출하면 됩니다. 이때, 디폴트로 Object 형태로 반환됩니다.

	Class<?> abcClass = Class.forName("com.example.reflection.ABC");
	Constructor<?> constructor = abcClass.getConstructor(String.class, int.class);
	// 기본 반환타입이 Object이므로, ABC 클래스 변수에 할당하려면 명시적 형변환이 필요합니다.
	ABC abc = (ABC) constructor.newInstance("HI", 123);

Class 클래스의 newInstance() 메서드를 이용해 인스턴스를 만들 수도 있지만, 이는 Java 9부터 Deprecated 되었기 때문에 Constructor 클래스를 활용해 인스턴스를 만드는 것이 권장됩니다.

메서드 다루기

Reflection을 이용하면 메서드는 물론 오버로딩된 메서드를 런타임 시간에 호출할 수 있습니다.

메서드 가져오기

Class 클래스의 getMethods() 또는 getDeclaredMethods()를 호출하면 해당 클래스의 메서드들을 불러옵니다.

	Class<?> abcClass = Class.forName("com.example.reflection.ABC");
	// 해당 클래스에서는 물론 상속한 클래스, 구현한 인터페이스에서 갖고있는 public 메서드들을 가져옵니다.
	Method methods1[] = abcClass.getMethods();
	// 해당 클래스 내에서 선언된 모든 메서드들을 가져옵니다.
	Method methods2[] = abcClass.getDeclaredMethods();

단일 메서드 가져오기

getMethod(함수 명, 인수 클래스...)또는 getDeclaredMethod()를 통해 단일 메서드를 불러올 수 있습니다. 이때 인자로 함수 명을(있다면 인수들의 타입 클래스까지) 넘겨주면 됩니다.

	Class<?> abcClass = Class.forName("com.example.reflection.ABC");
	// 해당 클래스 내에서 선언된 메서드 중 첫 번째 인자로 int를 받는 "make" 라는 메서드를 가져옵니다.
	Method method = abcClass.getDeclaredMethod("make", int.class);

메서드 호출하기

Method 클래스의 invoke(instance, 인자들) 메서드를 호출하면 해당 메서드를 실행할 수 있습니다.

	Class<?> abcClass = Class.forName("com.example.reflection.ABC");
	ABC abc = (ABC) abcClass.getConstructor().newInstance();
	// 해당 클래스 내에서 선언된 메서드 중 첫 번째 인자로 int를 받는 "make" 라는 메서드를 가져옵니다.
	Method method = abcClass.getDeclaredMethod("make", int.class);
	// abc 변수에 저장된 인스턴스로 make 라는 함수를 인자로 10을 넘겨 실행하는 코드입니다.
	method.invoke(abc, 10);

필드 값 다루기

Class 클래스의 getFields()또는 getDeclaredFields() 메서드를 호출하면 해당 클래스의 필드의 필드 값에 대한 정보를 갖는 Field 클래스들을 반환합니다.

	Class<?> abcClass = Class.forName("com.example.reflection.ABC");
	// ABC 클래스는 물론 부모 클래스, 구현한 인터페이스가 갖고있는 public 필드들을 가져옵니다.
	Field fields1[] = abcClass.getFields();
	// ABC 클래스내에서 선언된 모든 필드들을 가져옵니다.
	Field fields2[] = abcClass.getDeclaredFields();

단일 필드 가져오기

만약 하나의 필드 값을 가져오고 싶다면 getDeclaredField(fieldName) 또는 getField(fieldName)을 이용하면 가져올 수 있습니다.

만약 올바른 필드 이름을 넘기지 못했다면, NoSuchFieldException을 던지게 됩니다.

	Class<?> abcClass = Class.forName("com.example.reflection.ABC");
	// ABC 클래스는 물론 부모 클래스, 구현한 인터페이스가 갖고있는 public 필드들 중 "Number" 라는 이름의 필드를 가져옵니다.
	Field field1 = abcClass.getField("Number");
	// ABC 클래스내에서 선언된 필드들 중 "Age" 라는 이름의 필드를 가져옵니다.
	Field field2 = abcClass.getDeclaredField("Age");

필드 타입 가져오기

Field 클래스의 getType() 메서드를 호출하면 해당 필드의 타입 Class 객체를 반환합니다.

	Class<?> abcClass = Class.forName("com.example.reflection.ABC");
	Field field = abcClass.getField("Number");
	// "Number" 필드의 타입에 대한 정보를 갖는 Class를 반환합니다.
	Class<?> fieldClass = field.getType();

필드 값 가져오기

Field 클래스의 get(instance) 또는 getXXX(instance) 메서드를 호출하면 주어진 인스턴스에서 해당 필드가 어떤 값을 갖고있는지 반환합니다.

	// ABC 클래스는 int 타입의 Number 필드를 갖고 있습니다.
	Class<?> abcClass = Class.forName("com.example.reflection.ABC");
	ABC abc = (ABC) abcClass.getConstructor().newInstance();
	Field field = abcClass.getField("Number");
	// abc 변수에 저장된 인스턴스가 갖고있는 Number 필드 값을 반환합니다.

	// get() 메서드를 호출하면 Object 타입으로,
	// 여기서는 Number가 int 타입이므로, 래퍼 클래스인 Integer 타입으로 반환됩니다.
	Object fieldValue = field.get(abc);
	
	// getXXX() (XXX = Int, Boolean 등 원시 타입) 메서드를 호출하면 해당 타입으로 반환합니다.
	int fieldIntValue = field.getInt(abc);

	// 해당 필드의 디폴트 값을 가져오고 싶다면 instance로 null을 넘겨주면 됩니다.
	// 만약 정적 필드라면, 별도로 instance를 넘기지 않아도 값을 불러올 수 있습니다.
	// (instance를 넘겨도 해당 instance는 무시됩니다.)
	int defaultValue = field.get(null);

필드 값 바꾸기

Field 클래스의 set(instance, 값) 메서드를 호출하면 필드 값을 바꿀 수 있습니다. Field 클래스의 setAccessible(boolean) 메서드를 호출하면 필드 접근 가능 여부를 조작할 수 있습니다.

이때, 접근 가능 여부란, 실제 필드의 접근 제어자를 바꾸는 것이 아니라, AccessibleObject(여기선 Field)의 동작을 바꾸는 것입니다.

해당 값이 true인 경우 reflection의 대상이 된 객체(여기서는 Field)는 사용 될 때 자바 언어 접근 체킹(Java Language Access checking)을 억제해야 함을 의미합니다. 즉, 해당 객체를 사용할 때 이것이 public 인지 여부와 같은 것을 검사하는 액세스 검사가 이뤄지지 않음을 의미합니다.

	// ABC 클래스는 private으로 설정된 int 타입의 Number 필드를 갖고 있습니다.
	Class<?> abcClass = Class.forName("com.example.reflection.ABC");
	ABC abc = (ABC) abcClass.getConstructor().newInstance();

	// Number 필드를 가져왔지만 값에 접근할 순 없습니다.
	Field field = abcClass.getDeclaredField("Number");
	// java.lang.IllegalAccessException
	// Class "main이 존재하는 클래스 명" can not access a member of class ABC with modifiers "private"
	System.out.println(field.get(abc));
	// 해당 필드의 Accessible을 true로 바꾸었기 때문에 이제 접근할 수 있습니다.
	field.setAccessible(true);
	// "10"
	System.out.println(field.get(abc));

Reflection의 장점

동적 구성

Reflection이 동적 프로그래밍을 할 수 있게 해주어, 애플리케이션의 유연성과 융통성을 향사시킵니다. 이러한 장점은 필요한 클래스나 모듈이 런타임 시간 전에는 알 수 없는 경우 특히 유용합니다. Reflection의 유연함을 활용해, 개발자는 코드 변경의 번거로움 없이 실시간으로 구성을 바꿀 수 있는 시스템을 만들 수 있습니다.

예시 - Spring

일례로, Spring은 Reflection을 이용해 Bean들을 생성하고 구성합니다. 이러한 과정은 classpath 내 컴포넌트들을 감지하고 동적으로 인스턴스화 한 뒤, 애너테이션과 XML 설정을 바탕으로 구성하므로써 이뤄집니다. 이를 통해 개발자들은 소스 코드의 수정 없이 Bean을 추가하거나 수정할 수 있습니다.

확장성

Reflection을 이용해 개발자는 애플리케이션의 핵심 코드의 변경 없이 새로운 기능(Functionality)이나 모듈을 런타임에 포함시킬 수 있습니다. 예시로, 우리가 베이스 클래스를 정의하고 다형성 역직렬화(Polymorphic Deserialization)를 위해 여러 서브타입들을 통합하는 서드 파티 라이브러리를 쓴다고 가정하겠습니다. 이때, 우리는 베이스 클래스를 확장하는 자체 커스텀 서브타입을 도입해 기능을 확장하고자 합니다.
이러한 경우 Reflection을 사용하면 커스텀 서브 타입을 런타임에 동적으로 등록할 수 있고, 서드 파티 라이브러리와 쉽게 통합 할 수 있게 됩니다. 따라서, 우리는 코드를 변경치 않고, 라이브러리를 특정 요구사항에 맞게 조정할 수 있습니다.

다형성 역직렬화(Polymorphic Deserialization): JSON 직렬화/역직렬화 라이브러리인 Jackson의 특징 중 하나로, 하나의 부모와 여러 하위 클래스가 있을 때 역직렬화 시 객체의 올바른 실제 유형을 결정하는 것입니다.

코드 분석

소프트웨어 퀄리티를 높이기 위해 Reflection을 통해 코드를 동적으로 분석할 수 도 있습니다. 일례로 ArchUnit 이라는 자바 구조 단위 테스트 라이브러리의 경우, Reflection과 Bytecode 분석을 이용합니다.
만약 Reflection 단에서 가져올 수 없는 정보가 있다면, Bytecode 수준의 분석을 통해 정보를 가져옵니다.

Reflection의 단점

성능 오버헤드

Reflection은 동적으로 타입을 결정하기 때문에 이는 JVM의 최적화를 제한할 수 있습니다.
따라서 성능에 민감한 상황이라면 자주 호출되는 코드에서 Reflection 사용을 자제하는 것을 고려해야 합니다.

내부 사항의 노출

Reflection을 활용하면 그렇지 않은 코드에서는 제한될 수 있는 동작을 수행할 수 있습니다.
앞서 사용 용례에서도 보였듯이, private 필드와 메서드에 접근하고 조작할 수 있던 것이 그 예입니다. 이러한 행위는 객체지향 프로그래밍의 중요 원칙 중 하나인 캡슐화를 위반하는 행위입니다.

컴파일 시간 안전성의 손실

일반적인 Java 개발에선 컴파일러의 도움으로 타입 검사는 물론 클래스, 메서드, 필드가 올바르게 사용되는지 확인할 수 있습니다.
Reflection을 사용하면 이러한 검사가 이뤄지지 않으므로 탐지하기 힘든, 런타임 상에서 발생하는 버그를 유발할 수 있습니다.

코드의 유지보수성 저하

애플리케이션의 코드가 Reflection에 크게 의존할 경우, 코드 가독성이 떨어지게 되고 이는 유지보수성의 저하를 유도합니다. 또한 모든 개발 툴이나 IDE가 완전히 Reflection을 지원하지 않기때문에 몇몇 부분은 개발자가 수동으로 검사해야할 수 있습니다.

보안 문제

특정 환경에서 악성코드가 Reflection을 활용해 민감한 자원에 허가되지 않은 접근을 하거나, 보안 규정을 위반하는 동작을 수행할 수 있기 때문에 Reflection 접근을 허용토록 하는것은 위험합니다.

Reflection은 보안적인 문제가 있는가?

Reflection의 메서드들을 이용하면 private으로 선언된 값에 접근할 수 있어 객체지향 프로그래밍의 중요 원칙 중 하나인 캡슐화를 위반합니다.
따라서 특정 환경에서 악성코드가 Reflection을 이용해 중요한 리소스에 무단 접근하거나, 보안 정책을 위반할 수 있습니다.

방지책 - `Module`

Java 9 부터 도입된 Module을 사용하면 더 이상 내부를 노출하지 않을 수 있습니다. 또한, Reflection 액세스 권한을 부여할 수 있는 방법(open 키워드 사용)도 존재해 필요한 경우 내부를 들여다 볼 수 있게 할 수 있습니다.

Reflection은 어떻게 활용 가능할까?

앞서 나온 장점들의 예시처럼, Reflection은 동적인 객체 생성, 코드 분석 등 다양한 작업에 유용하게 사용할 수 있습니다. Spring, Hibernate와 같은 유명 라이브러리에서 의존성 주입, Bean 조작 등을 수행할 때, Reflection을 활용합니다.

참고 문서

[Java] JVM의 구조 간략하게 알아보기

Fri, 02 Feb 2024 13:19:37 +0900

서론

최근에 시작한 CS 스터디에서 첫 주제가 ‘JVM’에 관해 조사하는것으로 정해져 이를 문서로 정리 후 발표를 진행했었다.
이를 블로그에도 일부분 정리를 해서 포스팅하고자 한다.
여담으로 해당 문서를 작성하면서 최대한 Oracle과 같은 회사에서 올린 공식적인 문서를 참고하고자 노력했는데, JVM 구현을 위한 스펙 문서는 발견할 수 있었으나 총체적인 구조에 대한 정보는 없는 것 같아 GeeksforGeeks, Freecodecamp와 같은 학습 사이트도 참고하여 작성하였다.

JVM

JVM이란?

JVM(Java Virtual Machine, 자바 가상 머신) 은 Java Application을 실행하는 런타임 엔진 역할을 하는 컴포넌트로, JRE(Java Runtime Environment)의 일부입니다.

Java SE8 사양 문서의 설명

Java Platform의 주춧돌 역할을 하는 컴포넌트로 하드웨어 및 운영체제 독립성, 컴파일된 코드의 작은 크기, 악의적인 프로그램으로부터의 사용자 보호를 담당합니다.
JVM은 실제 컴퓨터처럼 추상적인 연산 기계입니다. 따라서 명령어 셋을 가지고 있고, 런타임에 다양한 메모리 영역을 조작합니다.
이러한 형태는 가상 머신을 쓰는 프로그래밍 언어를 구현하는데 있어 일반적인 형태로, JVM 이외에도 P-Code(UCSD Pascal), Squeak(Smalltalk) 등이 있습니다.
JVM의 첫 프로토타입은 썬-마이크로시스템에서 구현되었으며, PDA와 유사한 장비상에 호스팅되는 소프트웨어 안의 JVM 명령어 셋을 에뮬레이트 했습니다.
Oracle의 현재 구현은 JVM을 모바일, 데스크톱 및 서버장치상에서 에뮬레이트 하지만, JVM은 특정 구현 기술, 종속 하드웨어, 종속 운영체제를 가정하지 않습니다. 이는 선천적으로 해석(interpret)되지 않지만, JVM의 명령어 셋을 실리콘 CPU의 명령어 셋으로 컴파일링하므로써 구현할 수 있습니다.
유효한 클래스 파일로 표현될 수 있는 기능성(functionality)을 갖춘 모든 언어는 JVM에 의해 호스팅 될 수 있습니다.

JVM의 구조 #

JVM의 구조는 위 그림과 같습니다.
크게 클래스 로더, 메모리 영역, 실행 엔진 등으로 구성되어 있습니다.

클래스 로더(Class Loader)

클래스 로더는 클래스 파일을 로드하는데 사용되는 JVM의 하위 시스템입니다. 로딩(Loading), 링킹(Linking), 초기화(Initialization) 세 가지 동작을 담당합니다.

로딩(Loading)

클래스 로더가 .class 파일을 읽고, 대응되는 binary data를 생성해 JVM 메모리내의 메서드 영역에 저장합니다.
불러온 class와 해당 class의 바로 위 부모 클래스의 정규화된 이름, .class 파일이 클래스/인터페이스/Enum 중 어느것과 관련 있는지, 접근 제어자, 변수 및 메서드 정보 등 을 저장합니다.
.class 파일을 불러온 뒤, JVM은 Heap 메모리에 해당 파일을 표현하기 위해 Class(java.lang) 타입의 객체를 생성합니다.

개발자는 해당 클래스를 통해 클래스의 이름, 부모 클래스의 이름, 변수 및 메서드 정보 등을 얻을 수 있습니다.

링킹(Linking)

검증(Verification), 준비(Preparation), 해결(Resolution) 작업을 수행합니다.

검증(Verification): ByteCodeVerifier에 의해 .class 파일이 올바른 컴파일러에 의해 적절하게 포맷되고 생성되었는지 확인합니다.
만약 실패한다면 java.lang.VerifyError 라는 런타임 예외가 발생하게 됩니다.
준비(Preparation): 클래스 정적 변수(class static variable)에 대한 메모리를 할당하고, 메모리를 기본값으로 초기화합니다.
해결(Resolution): 객체를 이름으로 참조(Symbolic References)하는 것을 직접 주소 값을 참조하도록 대체합니다.
이 과정에서 이름으로 참조된 객체를 찾기 위해 JVM 메모리 내 메서드 영역을 검색합니다.

클래스 로더의 종류

클래스 로더는 3가지 종류가 있고, 각 클래스 로더들은 JVM의 위임-계층 원칙(Delegation-Hierarchy Principle) 을 따릅니다.
따라서, (클래스 로딩 요청) -> 시스템 -> 확장 -> 부트스트랩 순으로 클래스 로딩 요청을 위임하게 됩니다.
부트스트랩 경로에서 클래스가 발견되지 않으면 확장 클래스 로더에게 요청을 전송하고, 확장 클래스 로더도 찾지 못하면 시스템 클래스 로더에게 전송됩니다. 시스템 클래스 로더도 발견하지 못하면 런타임 에러(java.lang.ClassNotFoundException) 가 발생합니다.

부트스트랩 클래스 로더(Bootstrap class loader): %JAVA_HOME%/jre/lib에 존재하는 코어 Java API 클래스들을 불러옵니다. C/C++과 같은 네이티브 언어로 구현됩니다.
확장 클래스 로더(Extension class loader): 부트스트랩 클래스 로더의 자식으로, %JAVA_HOME%/jre/lib/ext 또는 java.ext.dirs 속성에 의해 정의된 디렉토리에 존재하는 클래스들을 불러옵니다. Java의 sun.misc.Launcher$ExtClassLoader 클래스로 구현됩니다.
시스템 클래스 로더(System/Application class loader): 확장 클래스 로더의 자식으로, 애플리케이션 classpath(내부적으로 java.class.path에 매핑된 환경 변수 사용)에 존재하는 클래스들을 불러옵니다. Java의 sun.misc.Launcher$AppClassLoader클래스로 구현됩니다.

초기화(Initialization)

부모 클래스에서 자식 클래스로, 클래스 내에서는 위에서 아래로 진행하며 모든 정적 변수(static variable)들을 코드 및 정적 블럭에 정의된 값으로 할당합니다.

JVM 메모리 영역(JVM Memory, Runtime Data Area)

메서드 영역(Method Area), 힙 영역(Heap Area), 스택 영역(Stack Area), PC 레지스터(PC Registers), 네이티브 메서드 스택(Native Method Stacks)으로 구성되어 있습니다.

공유 자원

메서드 영역(Method Area): 클래스 이름, 직속 부모 클래스 이름, 메서드 및 변수(정적 변수 포함)와 같은 모든 클래스 레벨 정보들이 저장됩니다. JVM 당 하나만 존재하며, 공유됩니다.
힙 영역(Heap Area): 모든 동적으로 생성된 객체(즉, 인스턴스)의 정보가 저장되어 있습니다. JVM 당 하나만 존재하며, 공유됩니다.

개별 자원

스택 영역(Stack Area): JVM이 각 스레드마다 사용할 런타임 스택을 생성하는 공간입니다. 런타임 스택의 모든 블록은 활성화 레코드(Activation Record) 또는 스택 프레임(Stack Frame)이라고 부르는 메서드 호출을 저장하는 블록입니다.
프레임에는 해당 메서드에서 사용되는 모든 로컬 변수가 저장됩니다. 런타임 스택을 사용하던 스레드가 종료되면 JVM에 의해 스택이 파괴됩니다.
PC 레지스터(PC Registers): 각 스레드 별로 존재하며, 스레드의 현재 실행 명령의 주소를 저장합니다.
네이티브 메서드 스택(Native Method Stacks): 각 스레드 별로 존재하며, 네이티브 메서드 정보를 저장합니다. 만약 네이티브 메서드를 호출할 때 매개변수를 넘겼다면 해당 매개변수를 저장합니다. 네이티브 메서드가 실행되면 스레드는 자바 스택에서 네이티브 메서드 스택으로 전환합니다.

실행 엔진(Execution Engine)

바이트 코드로 변환된 .class 파일을 한 줄씩 읽고 메모리 영역에 존재하는 데이터와 정보를 이용해 명령어를 실행합니다.
인터프리터(Interpreter), JIT 컴파일러(Just-In-Time Compiler), 가비지 컬렉터(Garbage Collector) 로 구성되어 있습니다.

인터프리터(Interpreter): 바이트 코드를 한 줄씩 해석하고 실행합니다. 인터프리터이기 때문에 한 메서드가 여러 번 호출될 떄 마다 매번 코드를 다시 해석합니다.
JIT 컴파일러(Just-In-Time Compiler): 인터프리터의 효율을 높이기 위해, 반복되는 메서드 호출에 대해 런타임에 바이트 코드를 컴파일해 네이티브 코드로 바꾼 뒤 직접 네이티브 코드를 제공합니다.
따라서 한 메서드를 여러 번 해석하지 않아 효율성이 향상됩니다.
JVM이 내부적으로 함수가 호출될 때 마다 호출 횟수를 카운트하다가, 임계점 이상 호출되는 경우 JIT 컴파일러를 통한 컴파일이 진행됩니다. 참고
가비지 컬렉터(Garbage Collector): 더 이상 참조되지 않는 객체들을 파괴합니다.

자바 네이티브 인터페이스(Java Native Interface, JNI)

네이티브 메서드 라이브러라와 상호작용하고, 실행에 필요한 네이티브 라이브러리(C/C++)를 제공하는 인터페이스 입니다.
JVM이 C/C++ 라이브러리를 호출하거나, 특정 하드웨어에서는 C/C++ 라이브러리에 의해 호출될 수 있도록 해줍니다.

네이티브 메서드 라이브러리(Native Method Libraries)

실행 엔진에 필요한 네이티브 라이브러리(C/C++)의 집합입니다.

JVM의 기능

바이트 코드를 포함하고 있는 .class 형태의 파일를 읽고, 검증한 뒤 실행합니다. 또한 해당 코드가 동작할 수 있는 런타임 환경을 제공합니다.

JVM 위에선 Java만 동작할 수 있나?

자바 이외에도 Scala, Kotlin, Groovy, Clojure 등 다른 언어들을 실행할 수 있습니다.
JVM에 의해 호스팅 될 수 있는 유효한 class 파일로 표현할 수 있는 기능(Functionality)를 가진 언어라면 JVM 상에서 실행될 수 있습니다.
또한 이들은 호환 가능한데, Scala의 라이브러리를 Java 프로그램에서 사용할 수 있는것이 그 예 입니다. #위키피디아 문서의 설명 #Scala에서 Java 라이브러리 사용하기

JVM 계열 언어를 기계어로 컴파일해서 쓸 순 없나?

가능은 합니다. Java의 경우 GNU Project에서 만든 GCC(GNU Compiler Collection)의 Java 컴파일러를 이용하면 네이티브 기계어로 컴파일해 사용할 수 있습니다.
하지만 가비지 콜렉터와 같은 런타임 지원을 받을 수 없기 때문에 정확하게 동작하지 않을 수 있습니다. #

JVM을 사용함으로써 얻을 수 있는 장/단점

장점

하드웨어 및 운영체제 독립성

C/C++과 같은 언어로 작성된 프로그램은

CPU마다 기계어가 다르고,
운영체제마다 API와 실행파일 형식이 다르기 때문에

프로그램이 개발된 환경과 다른 환경에서 실행하려하면 실행되지 않습니다.
반면 Java의 경우 JVM을 이용해 동일한 자바 실행 환경을 제공하므로 WORA(Write Once Run Anywhere), 즉 한 번 프로그램을 작성하기만 하면 어느 환경에서든 실행 할 수 있습니다.

다만 JVM 자체는 플랫폼에 종속적이므로 각 플랫폼마다 작성됩니다.

자동 메모리 관리

JVM 내부의 가비지 컬렉터가 계속해서 참조되지 않는 객체를 인식하고 파괴해 메모리 공간을 확보해줍니다. 따라서 개발자는 메모리 할당/할당 해제를 위해 별다른 작업을 수행하지 않아도 되고, 실수로 메모리 누수가 일어나거나 댕글링 포인터, 더블 프리와 같은 메모리 관련 오류를 줄일 수 있습니다.

댕글링 포인터(Dangling Pointer): 포인터가 참조중인 객체가 포인터의 수정 없이 삭제, 또는 할당 해제되어 포인터가 계속 할당해제된 메모리를 가리키는 메모리 보안 위반 현상입니다.
더블 프리(Double Free): 동일한 heap 메모리 공간에 대해 free(메모리 해제)를 두 번 시도해 발생하는 취약점입니다.
같은 인수로 free 함수를 두 번 호출할 경우, 메모리 관련 데이터 구조가 손상되어 프로그램이 중단되거나, 이후 두 번의 malloc() 명령에 대해 똑같은 포인터를 반환 할 수 있습니다. 이는 프로그램을 버퍼 오버 플로 공격에 취약하게 만듭니다. 참고

코드 가독성 및 유지보수성 향상

개발자가 로우-레벨 메모리 세부 사항에 대해 신경 쓸 필요가 없기 때문에 코드 가독성과 유지보수성이 향상됩니다.

단점

성능

Java의 하드웨어 및 운영체제 독립성에 의해, 바이트 코드를 특정 하드웨어나 시스템에 맞게 최적화시킬 수 없습니다.
또한 클래스에서 바이트 코드로, 바이트 코드에서 기계 코드로 두 번 변환하는 과정을 거쳐야 하기 때문에 C/C++과 같은 언어에 비해 느릴 수 밖에 없습니다.
또한 계속해서 객체 생성/삭제를 추적하고, 사용하지 않는 메모리를 회수하기 위해 가비지 컬렉터를 주기적으로 수행해 오버헤드가 발생합니다.
또한 GC 과정에서 자바 애플리케이션의 스레드가 멈출 수 있어 해당 어플리케이션의 응답 및 대기 시간에 영향을 미칠 수 있습니다.

JVM 자체

Java 프로그램이 JVM 자체에 의존하기 때문에, 희박한 확률이지만 JVM 자체가 오작동을 일으켜 에러가 발생할 수도 있습니다.

메모리 관리

JVM에서 메모리 할당 밎 관리를 수행하기 때문에, 수동으로 메모리 할당/할당 해제를 할 수 없습니다.

JVM과 그 위에서 실행되는 프로그램은 부모-자식 관계인가?

JVM과 그 위에 실행되는 프로그램은 부모 - 자식 관계를 갖는다고 보기 힘듭니다. JVM에서 관리하는 스레드를 통해 동작한다고 봐야 합니다.
JVM은 Java Application 코드를 실행하기 위해 main() 메서드를 실행하는 스레드를 포함해 하나 이상의 스레드를 관리합니다.
또한 자식 프로세스가 부모로 부터 완전히 독립적인 ‘부모 - 자식 프로세스’ 관계와 달리, Java Application은 JVM과 긴밀하고 JVM으로부터 메모리 할당, GC 등의 지원을 받습니다. 따라서 프로세스 - 스레드 관계에 있다고 봐야합니다.

참고 문서

빌더 패턴

Thu, 26 Oct 2023 02:22:40 +0900

디자인 패턴에서의 빌더 패턴과, Java에서의 빌더 패턴에 대해 알아보고자 한다.

디자인 패턴에서의 빌더 패턴

빌더 패턴은 복잡한 객체의 ‘구성’과 ‘표현’을 분리하여, 동일한 생성 절차가 다른 표현을 생성할 수 있도록 하는 패턴이다.
한 마디로, 복잡한 객체의 생성을 단계적이고, 관리 가능하며, 상호 교환 가능한 작업들로 분해하는 것이다.

구성 요소

디렉터(Director)

빌더 인터페이스를 사용해 객체의 생성을 조절하는 요소. 객체 생성의 순서를 명시함.

빌더 인터페이스(Builder Interface)

생성 단계에 대해 개략적으로 설명하는 요소.

콘크리트 빌더(Concrete Builder)

빌더 인터페이스를 구현하여, 각 생성 단계별 세부 사항을 제공하며 조합을 관리함.

프로덕트(Product)

생성 중인 복잡한 객체. 일반적으로 시스템은 디렉터와 프로덕트와만 접촉하고, 콘크리트 빌더의 존재는 알지못함.

참고
- Builder Pattern (Seperate construction of complex object : GofPatterns(gofpattern.com))
- Builder pattern - Wikipedia

Java에서의 빌더 패턴

점층적 생성자 패턴의 안정성과 자바빈즈 패턴의 가독성을 겸비한 패턴.
빌더 클래스는 보통 생성할 클래스 안에 정적 멤버 클래스로 만들어 두며, 이러한 빌드 패턴은 명명된 선택적 매개변수(Named Optional Parameters)를 흉내낸 것이다.

명명된 선택적 매개변수(Named Optional Parameters) : 위치 매개변수(Positional Parameters) 와 달리 값이 전달 될 때, 이름도 함께 전달되어야 하는 매개변수.

사용하게 된 배경

정적 팩토리 메서드와 public 생성자의 공통적인 단점인 ‘선택적 매개변수(Optional Parameter)‘가 많은 경우 적절한 대응이 힘들다는 점을 대처하기 위해 여러 패턴이 만들어지게 되었다.

점층적 생성자 패턴(Telescoping Constructor Pattern)

필수 매개변수만 받는 생성자, 필수 매개변수와 선택 매개변수 1개를 받는 생성자, … 형태로 선택 매개변수를 모두 받는 생성자까지 모든 경우의 수를 충족하는 방식이다.

단점

1. 사용자가 설정하기 원치않는 매개변수까지 포함하기 쉽다.

2. 매개변수 개수가 많아지면, 코드를 작성/읽는게 힘들다.

코드를 읽을 때, 각 값이 무엇을 의미하는지, 몇 개인지 파악하기 힘들고 실수로 순서가 바뀌면 런타임에 에러가 발생할 수 있다.

자바빈즈 패턴(JavaBeans Pattern)

매개변수가 없는 기본 생성자로 객체를 만든 뒤, setter 메서드를 호출해 원하는 필드의 값을 설정하는 방식이다.

장점

1. 인스턴스를 만들기 쉽고, 가독성도 좋다.

단점

1. 객체 하나를 만들기 위해 여러 메서드 호출이 필요하다.

2. 객체가 완전히 생성되기 전에는 일관성이 무너진 상태에 놓이게 된다.

점층적 생성자 패턴에서는 매개변수들의 유효 여부만 확인하면 일관성이 유지 되었지만, 자바빈즈 패턴에서는 그렇지 않음.

일관성 : 객체의 모든 프로퍼티들이 정상적으로 값들로 채워져 있는지 여부.

이러한 특성 때문에 자바빈즈 패턴에서는 불변 클래스를 만들 수 없고, 스레드 안정성을 위한 추가 작업이 수반된다.

이러한 단점을 보완하기 위해 객체를 freezing 하는 방법도 있지만, 개발자가 freeze를 호출했는지를 컴파일러가 보증할 수 없어 런타임 오류에 취약하다.

객체를 freeze하면, 속성 값을 수정하거나 삭제하는 것이 불가능해 진다. #

객체 생성과정

필수 매개변수로 생성자(또는 정적 팩토리 메서드)를 호출해 빌더 객체를 얻는다.
빌더 객체가 제공하는 setter 메서들로 원하는 선택 매개변수들을 설정한다.
매개변수가 없는 build 메서드를 호출해 (웬만하면 불변인)객체를 얻는다.

빌더의 setter 메서드들은 빌더 자신을 반환해, 연쇄적으로 호출하는 플루언트API(또는 메서드 연쇄)의 형태를 띈다.

플루언트 API(Fluent API) / 메서드 연쇄(Method Chaining) : 메서드 호출이 흐르듯 연결되는 형태. 소스 코드의 가독성을 산문과 유사하게 만드는 것이 목적이다.

유효성 검사

빌더 패턴을 사용할 땐 생성자 내에서, 그리고 build 메서드 내에서도 유효성 검사가 필요하다.

빌더 클래스는 생성할 클래스 내에 멤버 클래스로 존재하므로 클래스의 private 생성자에 접근할 수 있고, build 메서드는 보통 private 생성자를 호출하므로 해당 private 생성자 내에서 객체가 유효한 상태를 갖고 생성되는지 확인해야 한다.
빌더는 필드 값들이 복사 될 때 변형될 수 있어, 빌더의 필드가 아닌 defensive copy를 생성해 이 새로운 객체의 필드 값을 검증 해야한다. #
- 방어적 복사(Defensive Copy) : 가변적인 객체(Mutable Object)의 단점인 검사시점/사용시점 공격(TOC/TOU) 의 위험을 방지하기 위해, 직접 필드 값을 반환하지 않고 매 번 생성자를 활용해 필드 값을 새로운 객체로 반환하는 것. #

빌더와 계층적으로 설계된 클래스

빌더 패턴은 계층적으로 설계된 클래스와 조합이 좋다.
각 계층의 클래스에 관한 빌더를 멤버로 정의한다.
즉, 추상 클래스는 추상 빌더를, 구체 클래스(Concrete Class)는 구체 빌더를 갖게 한다.

구체 클래스(Concrete Class): 모든 메서드가 구현되어 있는, 즉 new 키워드를 통해 인스턴스를 만들 수 있는 클래스.

// 추상 클래스
public abstract class Pizza {
	...
	// 추상 빌더
    abstract static class Builder<T extends Builder<T>> {
		...
    }
    ...
}
// 구체 클래스
public class NyPizza extends Pizza {
	...
	// 구체 빌더
    public static class Builder extends Pizza.Builder<Builder> {
		...
    }
	...
}

이때, 추상 빌더 클래스는 재귀적 타입 한정(Recirsive Type Bound) 을 이용하는 제네릭 타입이다.

재귀적 타입 한정(Recursive Type Bound) : 타입 매개변수가 자신을 포함하는 수식에 의해 한정되는 것.
- ex) Builder<T extends Builder<T>>

추상 빌더에서 추상 메서드인 self를 하위 클래스에서 재정의(하위 클래스의 this 반환하도록)하게 해 상위<->하위 형변환 없이 메서드 연쇄를 할 수 있도록 한다. 이러한 방식을 시뮬레이트한 셀프 타입(Simulated Self-Type) 관용구라 한다.

// 추상 클래스
public abstract class Pizza {
	...
    abstract static class Builder<T extends Builder<T>> {
		...
        abstract **Pizza** build();
        // 하위 클래스는 이 메서드를 재정의(overriding)하여
        // "this"를 반환하도록 해야 한다.
        protected abstract T **self()**;
    }
}
// 구체 클래스
public class NyPizza extends Pizza {
	...
    public static class Builder extends Pizza.Builder<Builder> {
		...
        @Override public **NyPizza** build() {
            return new NyPizza(this);
        }
		// 재정의해 "this" 반환
        @Override protected Builder **self()** { return this; }
    }
}

또한, 하위 클래스의 빌더가 정의한 build 메서드는 해당하는 구체 하위 클래스를 반환하는, 공변반환 타이핑(Covariant Return Typing)을 이용해 형변환에 신경쓰지 않고 빌더를 사용 가능하다.

공변반환 타이핑(Covariant Return Typing) : 하위 클래스 메서드가 override 대상 메서드(상위 클래스의 메서드)가 정의한 반환 타입이 아닌, 그 하위 타입을 반환하는 기능.
- 즉, 위 코드처럼 NyPizza.Builder는 NyPizza를 반환. 빌더를 이용하면 가변인수(varargs) 매개변수를 여러 개 사용 가능하다. 이는 두 가지 방법이 있다.

각각을 메서드들로 나눠서 선언한다.
다른 매개변수들로 여러 번 호출한 뒤 이를 한 필드로 모은다.

빌더 패턴의 단점

1. 객체를 만들기 전 먼저 빌더부터 만들어야 한다.

2. 성능에 민감한 경우 문제가 될 수 있다.

3. 매개변수가 4개 이상은 되야 값어치를 한다.

점층적 생성자 패턴보다 코드가 장황해지기 때문에 제대로 값어치를 하려면 매개변수가 4개 이상은 되어야 한다.

정리

API는 대게 시간이 갈수록 매개변수가 많아지는 경향을 띄므로 애초에 빌더로 시작하는 편이 나은 경우가 많다.
다시 말하자면, 처리해야 할 매개변수가 많고 특히, 개중에 Optional한 매개변수가 많다면 빌더 패턴을 사용하는게 생성자, 정적 팩토리 메서드 보다 낫다.

정적 팩토리 메서드(Static Factory Method)

Wed, 25 Oct 2023 00:55:00 +0900

정적 팩토리 메서드란 무엇인지, 그리고 어떤 장점과 단점이 있는지를 정리해보고자 한다.

정적 팩토리 메서드(Static Factory Method)

클래스 인스턴스를 반환하는 단순한 정적 메서드이다.
public 생성자를 사용하는 방법과 함께 클래스의 인스턴스를 생성하는 대표적인 방법 중 하나이다.

예시 - `Boolean`클래스의 `valueOf`

public static Boolean valueOf(boolean b) {
  // 인자로 받은 boolean 값에 따라 Boolean 클래스 인스턴스를 반환한다.
  return b ? Boolean.True : Boolean.FALSE;
}

Effective Java의 Item.2.에 따르면 생성자 대신 정적 팩터리 메서드를 고려하라 라는데, 이를 통해 얻는 이점과 실은 무엇일까?

정적 팩토리 메서드의 장점

1. 이름을 가질 수 있다.

반환될 객체의 특성을 제대로 설명하지 못하는 생성자와 달리, 정적 팩토리 메서드는 이름만 잘 지으면 어떤 특성을 지녔는지를 쉽게 묘사 할 수 있다.
또한, 생성자는 한 시그니처에 하나의 생성자만 만들 수 있다. 이와 달리, 정적 팩토리 메서드는 이름을 가질 수 있기 때문에 시그니처가 같은 생성자가 여러 개 필요한 경우 이름을 통해 구분지을 수 있다.

시그니처: 함수의 이름, 공개 범위, 매개 변수 같은 함수에 대한 일반적인 정보. #

class A {
  int a
  // O
  public A(int a) {
    this.a = a;
  }
  // X : 이미 같은 시그니처의 생성자가 존재해 선언 불가
  public A(int b) {
    this.a = b;
  }
}

2. 호출될 때마다 인스턴스를 새로 생성하지 않아도 된다.

이러한 특성 덕분에 불변 클래스(immutable class)의 경우, (1)인스턴스를 미리 만들어 놓거나 (2)새로 생성한 인스턴스를 캐싱해 재활용하는 식으로 불필요한 객체 생성을 피할 수 있다.
이를 활용해 같은 객체(특히 생성비용이 큰)가 자주 요청되는 상황에 성능을 끌어올릴 수 있다.

불변 객체(Immuntable Objects): 모든 필드가 final, private이고, setter를 제공하지 않는 객체. 대표적인 예시론 String 클래스가 있다. #

또한, 언제 어느 인스턴스가 살아 있게 할지를 통제하는 인스턴스 통제 클래스(instance-controlled class) 와 같이 작동할 수 있다. 인스턴스를 통제하면 클래스를 싱글턴, 인스턴스화 불가로 만들 수 있다. 또한 불변 클래스에서 동치인 인스턴스가 단 하나임을 보장할 수 있다.
인스턴스 통제는 열거 타입이 인스턴스가 하나만 만들어짐을 보장한다.

3. 반환 타입의 `하위 타입 객체`를 반환 가능하다.

반환할 객체 클래스를 자유롭게 선택 할 수 있다. 이러한 유연함을 바탕으로 인터페이스 기반 프레임워크 를 만들 수 있다.

인터페이스 기반 프레임워크 : 인터페이스와 그 구현으로 설계된 프레임워크로, 구현자(implementor)에겐 구현에 대한 완전한 제어권을 제공하고, 클라이언트에게는 안정적인 API를 제공하는 이점이 있다.

Java 8 이전에는 인터페이스에 정적 메서드를 선언할 수 없어서 인터페이스 XXX를 반환하는 정적 메서드가 필요하면, XXXs라는 동반 클래스 (companion class, 인스턴스화 불가한 클래스)를 만들어 그 안에 정의해왔다.

Collection(인터페이스) 과 Collections(동반 클래스)가 대표적인 예시다.

Collection의 경우 부가 기능들을 포함한 유틸리티 구현체들이 인터페이스대로 동작할 것임을 예상할 수 있기 때문에 구현체들을 공개하지 않았고, API를 작고 가볍게 만들 수 있었다.

Java 8 이후 로는 인터페이스가 디폴트 메서드와 정적 메서드를 가질 수 있게 되므로써 동반 클래스를 둘 이유가 없어졌다.
다만, public static만 가능하므로 별도의 package-private 클래스에 둬야 할 수도 있다.
Java 9 에서는 private static 메서드도 지원하지만, static 필드와 static 멤버 클래스는 여전히 공개되어 있어야 한다.

4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.

반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체건 상관없다.
일례로 EnumSet 클래스의 경우, public 생성자 없이 정적 팩토리만 제공하는데 원소의 수(64개 이하, 초과)에 따라 두 하위 클래스(RegularEnumSet, JumboEnumSet) 중 하나의 인스턴스를 반환한다.

참고로, RegularEnumSet과 JumboEnumSet은 java 레퍼런스 사이트에는 명세되어 있지 않지만, IDE를 통해 EnumSet의 Declaration을 들어가보면 확인 가능하다.

// EnumSet.class
    public static <E extends Enum<E>> EnumSet<E> noneOf(Class<E> elementType) {
        Enum<?>[] universe = getUniverse(elementType);
        if (universe == null)
            throw new ClassCastException(elementType + " not an enum");

        if (universe.length <= 64)
        // 원소의 개수가 64개 이하면 RegularEnumSet을 반환.
            return new RegularEnumSet<>(elementType, universe);
        else
        // 원소의 개수가 64개 초과면 JumboEnumSet을 반환.
            return new JumboEnumSet<>(elementType, universe);
    }

클라이언트는 정적 팩토리가 반환하는 객체가 어떤 클래스의 인스턴스인지 알 수도, 알 필요도 없다.
오직 반환 타입인 EnumSet의 하위 클래스이기만 하면 된다.

5. 정적 팩토리 메서드를 작성할 당시엔 반환할 객체의 클래스가 존재하지 않아도 된다.

이런 유연함이 JDBC와 같은 서비스 제공자 프레임워크(Service Provider Framework)를 만드는데 근간이 된다.
서비스 제공자 프레임워크 는 서드파티가 서비스를 implement 하거나 extend해 제공자(provider, 서비스의 구현체) 를 구현하도록 의도된 API이며, 클라이언트에 구현체 제공하는것을 통제해 클라이언트 / 구현체를 분리한다.

구현체의 동작 정의된 서비스 인터페이스(Service Interface) 를 구현하는 구현체를 만든다.
제공자가 구현체를 제공자 등록 API(Provider Registration API) 를 통해 등록한다.
클라이언트가 서비스 접근 API(Service Access API, 정적 팩터리 메서드) 를 이용해 서비스 인스턴스를 얻는다. 이때, 어떤 구현체를 원하는지 조건을 명시할 수 있다.

이러한 방식을 통해, 제공자가 추후 구현체를 작성하여 프레임워크에 제공해도 정상적으로 작동할 수 있다.

이렇듯 다양한 장점이 있는 정적 팩토리 메서드이지만, 단점 역시 존재한다.

정적 팩토리 메서드의 단점

1. 정적 팩토리 메서드만 제공하면 하위 클래스 생성이 불가능하다.

상속을 하려면 public 또는 protected 생성자가 필요하기 때문이다.
따라서 개발자는 상속보다 컴포지션 을 사용하도록 유도된다.

컴포지션(Composition) : has-a 관계를 구현하기 위한 설계 기법으로, 객체가 다른 객체를 참조하는 인스턴스 변수를 사용하는 방법이다. #

2. 네이밍이 정확하지 않으면 다른 사람이 한 번에 알아채기 힘들다.

생성자 같이 API에 대한 설명이 명확히 드러나지 않아, 클라이언트는 정적 팩터리 메서드 방식을 채용한 클래스 의 인스턴스화 방법을 알아내야 한다.
따라서, API 문서의 명확한 작성과 적절한 네이밍 규칙을 통해 이를 방지해야 한다.

java on 오늘도 개발을 한다.

[Java] Exception 알아보기

서론

Java에서, Exception이란?

예외 처리 흐름

Exception의 종류

Checked Exception

Unchecked Exception

Runtime Exception

Error

Exception 방식의 장점

오류 처리 코드와 메인 로직 코드의 분리

예시

오류를 호출 스택으로 전파할 수 있음

예시

오류 타입의 그룹화 및 구분

예시

예외처리를 하는 세가지 방법

try-catch

try

catch

Union catch 절

finally

try-with-resources

throws

throw

예외처리가 성능에 끼치는 영향은 어느정도일까?

참고

[Java] synchronized 알아보기

서론

synchronized 키워드란?

키워드 위치에 따른 의미

인스턴스 메서드

정적 메서드

코드 블록

재진입성(Reentrancy)

효율적인 코드 작성 측면에서, synchronized는 좋은 키워드일까?

성능 저하

데드락

예상치 못한대로 동작할 수 있음

synchronized이외의 다른 동기화 기법

락 객체(Lock Object)

Volatile

원자 변수(Atomic variable)

ThreadLocal이란?

주의사항

참고 문서

[Spring] IoC와 DI 알아보기

서론

IoC와 DI란?

IoC (Inversion of Control, 제어의 역전)

Spring에서

장점

작업의 실행과 구현의 분리

쉬워지는 구현체 전환(switch)

프로그램 모듈성 향상

테스트의 용이함

DI (Dependency Injection, 의존성 주입)

Spring에서

유형

생성자 기반 DI (Constructor)

설정자 기반 DI (Setter)

필드 기반 DI (Field)

특정 기능을 하는 클래스가 하나인 경우 Bean 대신 구체 클래스를 사용해도 되지 않나?

결합도 증가

유연성 감소

테스트의 어려움

Spring의 Bean 생성 주기

Bean의 생성 범위(scope) 공식 문서

singleton

XML

Annotation

prototype

XML

Annotation

Bean의 Lifecycle

XML

Interface

Annotation

참고문서

`synchronized` 키워드란?

`인스턴스 메서드`

`정적 메서드`

`코드 블록`

`재진입성(Reentrancy)`

효율적인 코드 작성 측면에서, `synchronized`는 좋은 키워드일까?

`synchronized`이외의 다른 동기화 기법

`락 객체(Lock Object)`

`Volatile`

`원자 변수(Atomic variable)`

Bean의 생성 범위(`scope`) 공식 문서

`singleton`

`prototype`

`Constructor` 클래스로 인스턴스 만들기

방지책 - `Module`