멀티스레드 사용 시 가장 주의할 점은

여러 스레드가 같은 자원에 동시에 접근할 때 발생하는 동시성 문제다.

대표적인 공유 자원은 인스턴스의 필드(멤버 변수) 다.

synchronized 키워드를 붙이면, 한 번에 하나의 스레드만 실행할 수 있는 코드 구간을 만들 수 있다.

public class BankAccountV2 implements BankAccount {

  private int balance; // 잔액

  public BankAccountV2(int balance) {
    this.balance = balance;
  }

  @Override
  public synchronized boolean withdraw(int amount) {
    log("거래 시작: " + getClass().getSimpleName());
    log("[검증 시작] 출금액: " + amount + ", 잔액:" + balance);

    if (balance < amount) {
        log("[검증 실패] 출금액: " + amount + ", 잔액:" + balance);
        return false;
    }
    log("[검증 완료] 출금액: " + amount + ", 잔액:" + balance);
    sleep(1000); // 출금 소요 시간 1초
    balance -= amount;

    log("[출금 완료] 출금액: " + amount + ", 잔액:" + balance);
    log("거래 종료");
    return true;
  }

  @Override
  public synchronized int getBalance() {
      return balance;
  }
}

모든 인스턴스는 자신만의 Lock 을 가지고 있다.

• 이것을 모니터 락(monitor lock) 으로도 불린다.
• 객체 내부에 있는데 개발자가 확인하기는 어렵다.
• t1 스레드 작업이 종료되면, synchronized 블럭을 나갈 때, BankAccount 인스턴스의 락을 반납한다.
• BLOCKED 상태로 락 획득을 대기하는 t2 스레드는 자동으로 락을 획득한다.
  • t2 스레드 상태변경: BLOCKED → RUNNABLE
  • [참고] BLOCKED 상태인 스레드가 여러개일 때, 락을 획득하는 순서는 보장되지 않는다.
• t2 스레드는 검증 로직을 통과하지 못한다. 락을 반납하면서 return 한다.
• volatile 를 사용하지 않아도, synchronized 안에서 접근하는 변수의 메모리 가시성 문제는 해결된다.

BLOCKED 상태 스레드는

• 락이 풀릴 때 까지 무한 대기한다
• 중간에 인터럽트를 걸 수 없다
• BLOCKED 상태인 스레드가 여러개일 때, 락을 획득하는 순서는 보장되지 않는다
• → 순서를 모르니까 특정 스레드가 엄청 오래 기다리게 될 수도 있다.

synchronized 코드 블럭

synchronized 는 전체적으로 보면 성능이 떨어질 수 있다.

따라서 동시에 실행할 수 없는 코드 구간은 꼭! 필요한 곳으로 한정해서 설정해야 한다.

특정 코드 블럭만 synchronized 를 붙이자

• 메서드 단위가 아니라 특정 블럭에 최적화하여 적용할 수 있다.

public boolean withdraw(int amount) {
    log("거래 시작: " + getClass().getSimpleName());

    synchronized (this) {
        log("[검증 시작] 출금액: " + amount + ", 잔액:" + balance);
        if (balance < amount) {
            log("[검증 실패] 출금액: " + amount + ", 잔액:" + balance);
            return false;
        }
        log("[검증 완료] 출금액: " + amount + ", 잔액:" + balance);
        sleep(1000); // 출금 소요 시간 1초
        balance -= amount;
        log("[출금 완료] 출금액: " + amount + ", 잔액:" + balance);
    }
    
    log("거래 종료");
    return true;
}

• synchronized (this) {} 임계 영역을 코드 블럭으로 지정한다
• synchronized (this) : 여기서 괄호 안에 들어가는 값은 락을 획득할 인스턴스의 참조다.
  • 여기서는 BankAccountV3(x001) 의 인스턴스의 락을 사용하므로 이 인스턴스의 참조인 this 를 넣는다.

메모리 가시성 문제

• 멀티스레드에서 어려운 문제 중 하나가 메모리 가시성 문제다.
• 한 스레드가 변경한 값이 다른 스레드에서는 언제 보이는지에 대한 문제다
• 무슨 문제이고 왜 발생하고 어떻게 해결할 지 살펴보자.

일반적으로 생각하는 메모리 접근 방식

실제 메모리 접근 방식

• main 스레드가 runFlag = false 실행하면,
• main 스레드를 실행하는 CPU 코어의 캐시 메모리의 runFlag = false 부터 반영한다.
• 그래서 메인 메모리의 runFlag 값이 즉시 반영되지 않는다!

CPU 캐시 메모리

• 캐시 메모리를 사용하면 CPU 처리 성능을 개선할 수 있다.
• 코어1 캐시 메모리에 있는 runFlag 의 값이 언제 메인 메모리에 반영될까?
• 메인 메모리에 변경된 runFlag 값이 언제 CPU 코어2의 캐시 메모리에 반영될까?

→ 둘 다 “ 알 수 없다.” CPU의 설계 방식에 따라 다르다.

• 주로 컨텍스트 스위칭이 될 때, 캐시 메모리가 갱신된다.
• 하지만, 이것이 갱신을 보장하는 것은 아니다.

값을 읽을 때, 값을 쓸 때 모두 메인 메모리에 직접 접근하자!

자바에서는 volatile 키워드로 이런 기능을 제공한다.

volatile 키워드 적용하기

• 캐시 메모리 접근하지 말고, 메인 메모리 접근해!

public class VolatileFlagMain {

  public static void main(String[] args) {
      MyTask task = new MyTask();
      Thread t = new Thread(task, "work");
      log("runFlag = " + task.runFlag);
      t.start();

      sleep(1000);
      log("runFlag 변경 시도");
      task.runFlag = false;
      log("runFlag = " + task.runFlag);
      log("main 종료");
  }

  static class MyTask implements Runnable {
  
      volatile boolean runFlag = true;

      @Override
      public void run() {
          log("task 시작!");
          while(runFlag) {
              // runFlag 가 false 되면 탈출하자
          }
          log("task 종료");
      }
  }
}

• runFlag 변수를 false 바꾸는 순간 즉시 메인 메모리에 반영한다.
• 여러 스레드에서 같은 값을 읽고 써야 한다면, volatile 키워드를 붙이자.
• 단, 캐시 메모리를 쓸 때보다는 성능이 느려지는 단점이 있기 때문에 꼭 필요한 곳에서만 사용해야 한다.

스레드는 생성 → 시작 → 종료되는 생명주기를 가진다.

• 일단 실행 가능한 상태가 되면, 일시 중지 상태로 바뀔 수 있다
  • 참고: 자바에서 스레드의 ‘일시 중지 상태’ 라는 것은 없다.
  • 스레드가 기다리는 상태를 묶어서 설명하기 위해 사용한 용어다.

5가지 상태가 있다는 정도만 알아두자. 뒤에서 자세히 다루기 때문이다.

1. New (생성만 된 상태)

• Thread 객체가 생성되지만, start()메서드가 호출되지 않은 상태다.
• 예: Thread thread = new Thread(runnable)

2. Runnable (실행 가능 상태)

• 보통 실행 상태라고 부른다
• start() 메서드가 호출되면, 스레드는 이 상태로 들어간다.
• 이 상태에서 스레드는 실제로 CPU에서 실행될 수 있다. (이 상태에서만 CPU 스케쥴러에 들어가요!)
• 운영체제의 스케쥴러가 각 스레드에 CPU 시간을 할당하여 실행하기 때문에, Runnable 상태에 있는 스레드는 스케쥴러의 실행 대기열에 포함되어 있다가 차례로 CPU에서 실행된다.
  • 즉, 운영체제 입장에서 보면, CPU가 실제로 실행하는 스레드와 OS 스케쥴링 큐에 대기한 스레드 둘 다 포함이다.

3. Blocked (차단 상태)

• 동기화 락을 얻기 위해 기다리는 상태
• 예를 들어, synchronized 블록에 진입하기 위해 락을 얻어야하는 경우 이 상태에 들어간다.
  • 락은 스레드 하나만 가지고 있을 수 있다.

4. Waiting (대기 상태)

• 스레드가 다른 스레드의 특정 작업이 완료되기를 무기한 기다리는 상태
• 스레드는 다른 스레드가 notify(), notifyAll() 메서드를 호출하거나, join()이 완료될 때 까지 기다린다.
• wait(), join() 메서드가 호출되면 이 상태가 된다.
• 예: object.wait()

5. Timed Waiting (시간 제한 대기 상태)

• 스레드가 특정 시간 동안만 대기하는 상태
• 주어진 시간이 경과하거나, 다른 스레드가 해당 스레드를 깨우면 이 상태에서 벗어난다.
• sleep(long millis), wait(long timeout), join(long millis) 메서드 호출 시 이 상태가 된다.
• 예. Thread.sleep(1000);

6. Terminated (종료 상태)

• 스레드 실행이 완료된 상태.
• 스레드가 정상적으로 종료되거나 예외가 발생한 경우에 Terminated 가 된다.
• 스레드가 종료되면 다시 시작할 수 없다.

HelloThread - 스레드 생성

스레드를 생성해보자.

클래스에 Thread 를 상속 받고 run 메서드를 재정의하면 된다!

public class HelloThread extends Thread {
  @Override
  public void run() {
      System.out.println(
      Thread.currentThread().getName() + " : run()");
	}
}

HelloThreadMain

• 해당 코드를 실행하는 스레드 이름을 출력한다 Thread.currentThread().getName()
  • 그래서 메인 메서드를 실행하는 main 이라는 스레드명이 제일 처음에 출력된다.
  • 누가 이 코드를 실행하는지 스레드명을 확인하면서 학습하자.

public static void main(String[] args) {
  /** Thread.currentThread().getName() -> 스레드명이 main 이라고 출력된다 */
  System.out.println(Thread.currentThread().getName() + ": main() start");
  
  HelloThread helloThread = new HelloThread(); // HelloThread 객체를 생성
  System.out.println(Thread.currentThread().getName() + ": start() 호출 전 ");
  
  helloThread.start(); // start() 를 호출한다 ! 
  // 이 시점부터 main 스레드와 Thread-0 이 동시에 실행된다.
  
  System.out.println(Thread.currentThread().getName() + ": start() 호출 후 ");

  System.out.println(Thread.currentThread().getName() + ": main() end");
}

• HelloThread 인스턴스를 생성하고 HelloThread helloThread = new HelloThread()
  • 이것은 인스턴스 생성만 됬을 뿐, 스택 프레임이 할당된 게 아니다.
• start() 를 호출한다. helloThread.start()

중요 - 어느 시점에 새로운 스택 프레임이 생성될까 

• helloThread.start() 를 호출하면, HelloThread 의 스택 프레임이 생성된다.
• (main 스레드와는 별도의 스택 프레임이다)
• 그리고 HelloThread 가 run() 를 호출한다.
• 주의할 점은 main 스레드가 아니라, HelloThread 가 run() 을 호출한다는 점이다.
• main 스레드는 단지 helloThread.start() 호출을 통해서 다른 스레드에게 일을 시작하라고 지시할 뿐이다.

스레드 간의 실행 순서와 실행 기간을 둘 다 보장하지 않는다.

• 스레드는 동시에 실행되기 때문에 실행 순서는 얼마든지 달라질 수 있다.

main: main() start
main: start() 호출 전 
main: start() 호출 후 
Thread-0 : run()
main: main() end

• 실행 할 때마다 조금 달라진다. Thread-0 이 제일 밑에 출력될 때도 있다

main: main() start
main: start() 호출 전 
main: start() 호출 후 
main: main() end
Thread-0 : run()

정리

• 스레드 객체를 생성하고, 반드시 start() 를 호출해야 스택 공간을 할당 받고 스레드가 작동한다.
• 스레드는 순서와 실행 기간을 모두 보장하지 않는다! 이것이 멀티스레드다.

순서가 있고, 중복을 허용하는 자료구조를 List 라 한다.

• ArrayList 와 LinkedList 는 사용자 입장에서는 기능이 똑같다.
• 내부 구현만 다르므로 성능이 달라질 수 있다.

배열 리스트와 연결리스트 성능 비교

ArrayList 배열리스트

• 배열로 구성
• 인덱스를 통해 추가/삭제할 위치를 O(1) 로 빠르게 찾는다
• 추가 시, 데이터를 전부 한 칸씩 밀어야 해서 O(n)으로 오래 걸린다
• 배열이라서 메모리 상에서 연속적으로 위치하여 CPU 캐시 효율이 좋고 메모리 접근 속도가 빠르다.

LinkedList 연결리스트

• 이중 연결리스트로 구현되어 있다
• LinkedList 는 개별 노드가 앞/뒤 노드의 참조를 관리하므로 메모리 접근 속도가 배열에 비해서는 떨어진다
  • 인덱스를 제공하지 않으므로 순회해야 위치를 찾을 수 있다. O(n) 소요
  • 추가 시, O(n)으로 오래 걸린다
  • 해당 위치 찾는데 O(n) 소요되고, 참조 변경은 O(1) 소요
• 만약, 데이터를 앞쪽에 자주 추가/삭제 할 일이 있다면, 연결 리스트를 고려하자

HelloThread - 스레드 생성

스레드를 생성해보자.

클래스에 Thread 를 상속 받고 run 메서드를 재정의하면 된다!

public class HelloThread extends Thread {
  @Override
  public void run() {
      System.out.println(
      Thread.currentThread().getName() + " : run()");
	}
}

HelloThreadMain

• 해당 코드를 실행하는 스레드 이름을 출력한다 Thread.currentThread().getName()
  • 그래서 메인 메서드를 실행하는 main 이라는 스레드명이 제일 처음에 출력된다.
  • 누가 이 코드를 실행하는지 스레드명을 확인하면서 학습하자.

public static void main(String[] args) {
  /** Thread.currentThread().getName() -> 스레드명이 main 이라고 출력된다 */
  System.out.println(Thread.currentThread().getName() + ": main() start");
  
  HelloThread helloThread = new HelloThread(); // HelloThread 객체를 생성
  System.out.println(Thread.currentThread().getName() + ": start() 호출 전 ");
  
  helloThread.start(); // start() 를 호출한다 ! 
  // 이 시점부터 main 스레드와 Thread-0 이 동시에 실행된다.
  
  System.out.println(Thread.currentThread().getName() + ": start() 호출 후 ");

  System.out.println(Thread.currentThread().getName() + ": main() end");
}

• HelloThread 인스턴스를 생성하고 HelloThread helloThread = new HelloThread()
  • 인스턴스 생성만 됬을 뿐, 스택 프레임이 할당된 게 아니다.
• start() 를 호출한다.

helloThread.start() 를 호출하면, HelloThread 의 스택 프레임이 생성된다.

(main 스레드와는 별도의 스택 프레임이다)

그리고 HelloThread 가 run() 를 호출한다.

주의할 점은 main 스레드가 아니라, HelloThread 가 run() 을 호출한다는 점이다.

main 스레드는 단지 helloThread.start() 호출을 통해서 다른 스레드에게 일을 시작하라고 지시할 뿐이다.

• 스레드는 동시에 실행되기 때문에 실행 순서는 얼마든지 달라질 수 있다.

main: main() start
main: start() 호출 전 
main: start() 호출 후 
Thread-0 : run()
main: main() end

• 실행 할 때마다 조금 달라진다. Thread-0 이 제일 밑에 출력될 때도 있다

정리 

• 스레드 객체를 생성하고, 반드시 start() 를 호출해야 스택 공간을 할당 받고 스레드가 작동한다.
• 스레드는 순서와 실행 기간을 모두 보장하지 않는다!

Runnable 인터페이스

• 자바가 제공하는 스레드 실행용 인터페이스다.

public interface Runnable {
		void run();
}

어떻게 사용하는지 살펴보자.

HelloRunnable implements Runnable

public class HelloRunnable implements Runnable {
  @Override
  public void run() { // run() 내에 작업 로직을 구현한다 
      System.out.println(Thread.currentThread().getName() + ": run()");
  }
}

HelloRunnableMain

• 실행 결과는 기존과 같다.
• 차이가 있다면, Thread 와 해당 스레드가 실행할 작업이 분리되어 있다는 점이다.
• Thread 객체를 생성할 때, 생성자로 작업 클래스를 전달한다.

public class HelloRunnableMain {
  public static void main(String[] args) {
    System.out.println(Thread.currentThread().getName() + ": main() start");

    HelloRunnable runnable = new HelloRunnable(); // 작업 정의
    Thread thread = new Thread(runnable); // 스레드
    thread.start();

    System.out.println(Thread.currentThread().getName() + ": main() end");
  }
}

Runnable 인터페이스 구현하는 방식이 더 나은 이유!

Thread 클래스 상속 방식의 단점

• 자바는 단일 상속만을 허용하므로, Thread 클래스를 상속받으면, 다른 클래스를 상속받을 수 없다.
• 인터페이스를 사용하는 방식에 비해 유연성이 떨어진다.

Runnable 인터페이스를 구현하는 방식

• 상속의 자유로움
• 코드의 분리: 스레드와 실행할 작업은 분리하여 코드의 가독성을 높일 수 있다.
• 여러 스레드가 동일한 Runnable 객체를 공유할 수 있어 자원 관리를 효율적으로 할 수 있다!

목차

1. 예외 계층 

2. 예외 기본 규칙

3. 체크 예외

4. 언체크 예외 (런타임 예외)

1. 예외 계층

예외 처리는 아래 키워드를 사용한다

try, catch, finally, throw, thorws

• Obejct: 자바에서 기본형을 제외한 모든 것은 객체다. 예외의 최상위 부모도 Object 다.
• Throwable: 최상위 예외 객체다. 하위에 Exception 과 Error 가 있다.
• Error: 메모리 부족이나 심각한 시스템 오류와 같은 애플리케이션에서 복구 불가능한 시스템 예외다.
  • 애플리케이션 개발자는 이를 잡으려고 해선 안 된다.

• Exception
  • 애플리케이션 로직에서 사용할 수 있는 최상위 예외다.
• 체크 예외
  • RuntimeException 을 제외하고는 모두 컴파일러가 체크하는 예외다
  • 개발자가 체크 예외를 처리하지 않으면 컴파일 오류가 발생한다.
• 언체크 예외 (런타임 예외)
  • 컴파일러가 체크하지 않는다.
  • RuntimeException 과 그 자식 예외는 모두 언체크 예외다

주의

• 상속 관계에서 부모 타입은 자식을 담을 수 있다. 이 개념이 예외 객체에서도 적용된다.
  • 상위 예외를 catch 로 잡으면, 하위 예외 까지 함께 잡는다.
• 따라서 애플리케이션 로직에서는 Throwable 예외를 잡으면 안된다. 애플리케이션 개발자가 잡으면 안 되는 Error 예외 까지 같이 잡을 수 있기 때문이다.
• 이런 이유로 애플리케이션 로직에서는Exception 부터 ‘처리가 필요한 예외’로 여기고 잡으면 된다.

2. [중요] 예외 기본 규칙

예외는 폭탄 돌리기와 같다. 잡아서 밖으로 던지거나, 처리하거나.

• 예외를 처리하지 못하면, 자신을 호출한 곳으로 예외를 던져야 한다.
• 예외를 잡거나 던질 때, 지정한 예외 뿐만 아니라 그 예외의 자식 예외도 함께 처리할 수 있다!
• 예외를 처리하지 못하고 계속 던지면 어떻게 될까?
  • 자바 main() 밖으로 예외로 던지면, 예외 로그를 출력하면서 시스템이 종료된다.

3. 체크 예외

• Exception 과 그 하위 예외 모두는 컴파일러가 체크하는 체크 예외다.
  • RuntimeException 은 제외다. 언체크 예외다.
• 체크 예외는 잡아서 처리하거나, 자신을 호출한 곳으로 던져야 한다. 그렇지 않으면 컴파일 오류가 발생한다.

Exception 을 상속받은 예외는 체크 예외가 된다.

• MyCheckedException 예외 클래스를 만들자.
  • Exception 을 상속받으면 된다.

public class MyCheckedException extends Exception {
    public MyCheckedException(String message) {
        super(message);
    }
}

• super(message)
  • Exception 에는 message 를 보관하는 생성자가 있다.
  • Throwable 의 detailMessage 에 저장된다.

• 보관한 message 를 꺼내려면, Throwable 에서 제공하는 getMessage() 메서드로 꺼낸다

throw VS throws 헷갈리지 말기

• throws : 예외를 메서드 밖으로 던질 때 쓰는 키워드다
• throw : 예외를 발생시킨다.
  • new 로 객체를 생성하고 예외를 발생시킬 수 있다
  • throw new MyCheckedException(”msg”)

Client class : 예외 발생하면 밖으로 던지기

• call() throws MyCheckedException → MyCheckedException 가 발생하면 메서드 밖으로 던진다
• throw new MyCheckedException("ex") → 예외 객체를 생성하여 예외를 발생시킨다.

public class Client {
  
  public void call() throws MyCheckedException { // throws 예외 던지기 

      // throw 예외 발생 
      throw new MyCheckedException("ex");
  }
}

예외를 잡아서 처리하기

• try catch 를 사용해서 예외를 잡으면 된다.
• client.call() 호출하면, MyCheckedException 이 발생하여 예외 객체가 넘어온다.
• catch 블럭 내에 예외 처리 로직을 작성한다.

public void callCatch() {

  try {
      client.call();
  } catch (MyCheckedException e) { // 예외 처리 로직
      
      System.out.println("예외 처리, message=" + e.getMessage());
      // 예외 처리 후, 정상 흐름으로 간다.
  }

  System.out.println("정상 흐름");
}

catch 의 대상에 없는 예외라면?

• try 에서 잡은 예외가 catch 의 대상에 없으면 예외를 잡을 수 없다. 이때는 예외를 밖으로 던져야 한다.
• catch 대상을 RuntimeException 으로 바꿔보면, 컴파일 에러가 발생한다!
  • unreported exception: exception.basic.checked.MyCheckedException;
  • must be caught or declared to be thrown → 잡거나 던진다고 선언하세요.

그 예외의 자식 예외도 함께 처리하기

• MyCheckedException 은 Exception 을 상속 받은 체크 예외 클래스다.
• catch 대상을 MyCheckedException 대신 Exception 으로 바꿔서 실행해보자.

public void callCatch() {

    try {
        client.call();
    } catch (Exception e) { // 예외 처리 로직
        
        System.out.println("예외 처리, message=" + e.getMessage());
    }

    System.out.println("정상 흐름");
}

• 실행 해보면, MyCheckedException 예외를 catch 로 잡아서 처리한 것을 확인할 수 있다

예외를 메서드 밖으로 던지기 throws

• client.call() 호출하면, MyCheckedException 이 발생하여 예외 객체가 넘어온다.
• 여기서는 메서드에 선언한 throws 로 예외를 메서드 밖으로 던진다.
• 체크 예외를 밖으로 던지려면, throws 예외를 메서드에 필수로 지정해야 한다.

public void catchThrow() throws MyCheckedException {
    client.call();
}

정리

• 체크 예외는 개발자가 명시적으로 처리해야 한다. 처리 안하면, 컴파일 오류 난다.
• try-catch 로 잡아서 처리 하거나, 메서드에 throws 를 지정해서 예외를 밖으로 던진다는 선언을 필수로 해야 한다.

4. 언체크 예외 (런타임 예외)

• 컴파일러가 예외를 체크하지 않는다.
• 언체크 예외는 체크 예외와 기본적으로 동일하다. 한 가지 차이가 있다. throws 를 생략할 수 있다.
• throws 를 생략해도, 자동으로 예외를 밖으로 던진다.

체크 예외 VS 언체크 예외

• 체크 예외: 예외를 처리하지 않는 경우, throws 로 던져야만 컴파일 오류가 안 난다.
• 언체크 예외: throws 를 생략해도, 자동으로 예외를 밖으로 던진다.

언체크 예외 예제코드

• 언체크 예외 클래스 RuntimeException 을 상속받은 예외는 언체크 예외가 된다.

public class MyUncheckedException extends RuntimeException{
    public MyUncheckedException(String message) {
        super(message);
    }
}

• 언체크 예외를 발생시키는 Client 클래스
  • 체크 예외와는 다르게, 메서드에 throws 키워드를 생략했다.

public class Client {

    public void call() { // 메서드에 throws 키워드 생략 
        throw new MyUncheckedException("unckecked exception! ");
    }
}

• Client 클래스 메서드를 호출하는 Service 클래스

public class Service {
    Client client = new Client();

    public void callCatch() { // 필요한 경우, 예외를 잡아서 처리할 수 있다.
        
        try {
            client.call();
        } catch (MyUncheckedException e) {
            System.out.println("예외 처리, message: " + e.getMessage());
        }
        System.out.println("정상 로직");
    }
    
    /** 
     * 예외를 잡지 않아도 컴파일 에러가 안나고, 상위로 올라간다. 
     * */
    public void callThrow() {
        client.call();
    }
}

• 예외 잡아서 처리하는 메서드 callCatch() 호출하여 실행

public class UncheckedCatchMain {
    public static void main(String[] args) {
        Service uncheckedService = new Service();
        uncheckedService.callCatch();
        System.out.println("정상 종료");
    }
}

• 실행 결과

예외 처리, message: my unckecked exception! 
정상 로직
정상 종료

• 예외를 호출부로 던지는 callThrow() 메서드를 호출하여 실행

public class UncheckedCatchMain {
    public static void main(String[] args) {
        Service uncheckedService = new Service();
        uncheckedService.callThrow();
        System.out.println("정상 종료");
    }
}

• 실행 결과
  • callThrow() 메서드에 throws 키워드가 없어도, 컴파일 오류가 나지 않는다.
  • callThrow() 메서드가 실행 되었고, callThrow() 에서 예외를 잡아서 처리하지 않았기 때문에 main() 으로 언체크 예외가 넘어왔다.
  • main() 에서도 MyUncheckedException 을 처리하지 않고 있어서 main() 도 예외를 밖으로 던진다.
  • callThrow() 까지만 실행 됬으니까, 다음 줄에 있는 “정상 종료” 출력이 실행되지 않는다.
  • 이렇게 되면 예외 정보와 스택 트레이스가 출력되면서 프로그램이 종료된다.

Exception in thread "main" exception.basic.unchecked.MyUncheckedException: my unckecked exception! 
	at exception.basic.unchecked.Client.call(Client.java:6)
	at exception.basic.unchecked.Service.callThrow(Service.java:23)
	at exception.basic.unchecked.UncheckedCatchMain.main(UncheckedCatchMain.java:7)

정리

• 신경쓰고 싶지 않은 언체크 예외를 무시할 수 있다는 장점이 있다. throws 예외를 생략 가능!
• 하지만, 컴파일러를 통해 예외 누락을 잡을 수는 없다.
• 현대 애플리케이션에서는 체크 예외를 거의 쓰지 않는다.

인프런 김영한 자바 중급1 강의를 듣고 요약한 내용입니다.