[자바 최적화] 최적화와 성능 정의

자바 최적화 들어가며

자바 최적화에 대한 글을 검색하다 보면, 과거 JVM 환경을 기준으로 한 이야기들이 아직도 상위에 랭크되어 있는 경우가 많습니다.
예를 들어, "메서드 디스패치 성능을 위해 작은 메서드를 만들지 말고, 큰 메서드 하나로 작성하라" 라는 조언이 있습니다.
하지만 현재의 JVM에서는 이런 최적화는 큰 의미가 없습니다. 이유는 JIT(Just-In-Time) 컴파일러의 발전 덕분에 메서드 디스패치 오버헤드가 더 이상 병목이 아니기 때문입니다.

 

메서드 디스패치란?

메서드 디스패치(Method Dispatch)는 "메서드를 호출할 때 어떤 구현을 실행할지 결정하는 과정"을 의미합니다.

- 오버로딩(Overloading) → 컴파일 시점에 호출 메서드가 결정 (정적 디스패치)

- 오버라이딩(Overriding) → 런타임 시점에 실제 객체 타입을 보고 호출 메서드가 결정 (동적 디스패치)

 

과거의 JVM에서 병목이 되었던 이유 JVM이 메서드를 실행할 때는 다음 과정을 거치기 때문입니다.

obj.hello() 호출

-> 참조 타입은 Parent지만, 실제 객체 타입은 Child

-> JVM은 클래스 로딩 시 생성된 vtable(virtual method table)에서 hello()가 가리키는 실제 구현의 주소를 찾아 호출

 

vtable: 클래스 로딩 시점에 생성되는 메서드 주소 테이블로, 오버라이드된 메서드의 실제 실행 주소를 빠르게 찾기 위해 사용됩니다.

과거 JVM(특히 JIT 최적화가 미흡했던 시절)에는 이 vtable 조회 과정과 메서드 호출 오버헤드가 잦으면 병목이 될 수 있었고, 그래서 "작은 메서드를 자주 호출하지 말라"는 조언이 있었습니다.

class Parent {
    void hello() { System.out.println("Parent"); }
}

class Child extends Parent {
    @Override
    void hello() { System.out.println("Child"); }
}

public class Main {
    public static void main(String[] args) {
        Parent obj = new Child();
        obj.hello(); // "Child"
    }
}

현재 JVM에서는 왜 문제가 안 되는가?

현대 JVM은 JIT 컴파일러를 통해 메서드 인라이닝(Method Inlining)을 수행합니다.

메서드 인라이닝이란 자주 호출되는 작은 메서드의 호출 코드를 메서드 본문 코드로 직접 치환하는 최적화 기법입니다.

int square(int x) {
	return x * x;
}

=> result = value * value;

처럼 변환해 버립니다.

이렇게 하면:

- vtable 조회 과정 제거

- 호출 스택 생성/해제 오버헤드 제거

- 추가적인 최적화(상수 폴딩, 루프 전개 등) 가능

즉, 과거의 "메서드 호출 성능" 문제는 JIT 인라이닝 덕분에 사실상 사라진 셈입니다.

 

자바 성능 측정 지표

Throughput (처리량) 단위 시간당 처리 작업 수 초당 거래 건수
Efficiency (효율성) 처리량 / 사용 자원량 TPS / CPU 사용량
Latency (지연 시간) 요청 시작부터 완료까지 걸린 시간 API 응답 시간
Scalability (확장성) 자원 추가 시 처리량 변화율 서버 2대 → 4대 시 TPS 변화
Capacity (수용량) 동시에 처리 가능한 작업량 최대 동시 접속자 수
Degradation (성능 저하) 부하 증가에 따른 성능 감소 비율 80% 부하 시 응답시간 증가율
Utilization (활용도) 자원 사용 비율 CPU/메모리 사용률
Idle Time (유휴시간) 시스템이 아무 작업도 안 하는 시간 비율 CPU idle time