모의면접 스터디를 시작하게된 계기 

면접 울렁증 때문에 난 왜 이모양일까 자책하다가 JSCODE 모의 면접 스터디가 있길래 신청했다. 

 

Situation 스터디 개요 

  • 5주 동안 금요일 밤마다 2시간 동안 모의 면접 및 멘토링 (멘토링 30분 + 모의면접 90분 이상)
  • 모의 면접 구성원: 3~5인
  • 과목: 자바, DB, OS, 네트워크 (두 과목 동시 수강은 안 된다고 한다. 이 점이 좀 아쉽다)
  • 비용: 스터디 운영비 + 예치금 합해서 20만원. 과제 및 스터디 모두 참여 시 10만원 돌려받는다.

Task

  • 매주 기술면접 약 20~30개 질문과 인성면접 질문이 공개된다.
  • 질문들과 관련된 주제들을 공부해야 한다. 공부 내용을 블로그에 게시 후 링크를 구글폼에 제출해야 과제 수행이 인정된다. 
  • 3~5인 으로 구성된 팀 매칭 표를 보고 줌 소회의실로 접속하면 된다. 
  • 아무래도 여러 사람으로부터 자세하게 피드백을 받다보니 메타인지를 키우게 되는 효과가 있다!
    • 피드백 작성하는 시간에 면접자의 장점과 개선할 점을 써야 한다. 면접자를 관찰하면서 장점을 발견하는 연습을 하니깐 내 시각이 긍정적인 사람으로 변하는? 그런 긍정적인 효과가 있었다.
    • 스터디원들 모두 자세하게 피드백 해주셔서 감사했다. 개선할 점을 서로 피드백 해줘야 하는데, 이 과정에서 혹시 상처가 될까봐 다들 둥글게 말씀해주셨다.

Action 

  • 딱 주제별로 면접 준비를 연습하다보니 그 내용을 90분 동안 묻고, 대답하고, 옆에서 들으면서 외워지는 효과가 있었다. 
  • 그리고 어려운 내용들은 같이 어려워 하니깐 위로가 된다 (?) 
  • 공부 내용을 글로 작성해야되니까 내가 아는 내용을 구조화해서 한 번 더 들여다보게 된다. 

Result 

  • 모의 면접도 면접이기 때문에 신청해놓고 너무 하기가 싫었다 (정말 바보) 첫 회 해놓고 바로 뿌듯해했다.(!!)
  • 자바 면접에 자신감이 생겼다. 신청하길 잘 했다. 이직이나 취준하는 사람들 이 스터디 신청 꼭 하세요 추천입니다. 
  • 두괄식으로 답변하는 연습이 더 필요하다.
  • 멘토님들께 질문 여러개 해야지 싶었는데. 한 개도 안 했다.. 아쉽다. 돈도 아깝다.
  • 성실하게 스터디 같이 했던 분들 떠올려서 모의 면접 스터디 이어서 하자는 DM 보냈다. 3명~4명 정도 모이면 8회 해보려고 한다. 

느낀점 

  • 면접 준비가 쉽지 않은데, 고생을 같이 하다보니 덜 힘들다.
  • 주기적으로 여러 사람과 긴장하는 시간에 노출되다보니 심장소리가 내 귀에 들리던 긴장도 서서히 무뎌진다. 
  • 멘토링 중에 익명으로 질문하고 멘토님이 대답해주시는 시간이 있다. 요 시간이 유용했다.
  • 멘토 분들이 매우 친절하고 섬세하시다. 날카로운 질문들도 좋았다. 스터디 끝나고나서 이력서 첨삭도 받을 수 있다. 
  • 이 기세를 몰아서 아자아자 화이팅! 
728x90

'일상 > 회고' 카테고리의 다른 글

2023년 새해계획  (0) 2023.01.31
주니어 개발자 2022년 회고  (0) 2023.01.31

 

JVM 이란 

  • java 바이트코드를 실행하기 위한 가상머신이다.
  • 컴파일러: 자바 소스 코드는 컴파일러가 바이트 코드로 변환한다.

JVM의 구성

  • 클래스 로더, 실행 엔진, 런타임 데이터 영역, 네이티브 인터페이스 로 구성한다.
  • 클래스 로더: 클래스 파일을 메모리에 가져온다
  • 실행 엔진: 바이트 코드를 실제로 실행한다.
  • 런타임 데이터 영역: 런타임에 필요한 메모리를 관리한다
  • 네이티브 인터페이스: c/c++ 등 자바 외부 코드와 연결할 때 사용한다.

JVM 메모리 구조 

  • 메소드 영역: 지역변수나 호출 정보를 저장한다.
  • 힙: 동적으로 할당하는 객체가 저장되는 공간
  • 스택: 스레드별로 생성된다.
  • PC레지스터: 현재 실행중인 jvm 명령의 주소를 저장한다.
  • 네이티브 메서드 스택: jni 를 통해 호출되는 네이티브 코드의 스택이다.

 

GC (Garbage Collection)

  • 더이상 참조되지 않는 객체를 메모리에서 제거하는 기능이다. 
  • 메모리 관리를 자동화 해주니까 개발자의 부담이 줄어든다는 장점이 있다. 
  • 단점
    • 객체를 메모리에서 제거하려면 일시적으로 애플리케이션이 멈춰야 한다. 이 타이밍을 개발자가 예측하기는 어렵다 
    • 따라서 실시간성이 중요한 시스템에서는 부적합할 수 있다 

 

GC 를 모니터링 해야 하는 이유

  • GC 가 자주 발생하면 애플리케이션 성능이 저하될 수 있다. 따라서 얼마나 자주, 얼마나 오래 멈추는지 확인해야 한다. 
  • 이를 통해 메모리 사용량이 적절한지, 어느 객체가 오래 살아남는지 등을 알 수 있다. 이를 기반으로 튜닝 포인트를 찾는다. 

 

메모리 누수를 어떻게 확인할 수 있을까 

  • 메모리 누수는 객체가 참조된 상태로 계속 남아 GC 가 제거하지 못할 때 발생한다. 
  • JVisualVM, Eclipse MAT 같은 도구로 힙 덤프를 분석할 수 있다. 
    • 어떤 클래스가 얼마나 많은 객체를 가지고 있는지, 참조 체인이 어떻게 되는지 시각적으로 보여준다.

 

GC 에서 사용하는 알고리즘 

 

1. Mark and Sweep

2. 카피 알고리즘 

3. Generation GC 

    객체가 얼마나 오래 생존하는지에 따라 관리 

4. Parallel GC (-> 자바 8 이 기본으로 채택한 방식) 

 

 

Java 8 기준으로 GC 는 어떤 방식으로 수행될까 

  • 힙 메모리를 Young Generation과 Old Generation으로 나눠 관리한다
  • Young 영역에서 발생하는 GC를 Minor GC, Old에서 발생하는 GC를 Major GC 또는 Full GC라고 한다
  • Young 영역은 Eden과 Survivor 영역 두 개로 나뉘고, 새로 생성된 객체는 Eden에 저장한다.
    • Eden이 가득 차면, GC가 실행되고 살아남은 객체는 Survivor 영역으로 이동한다 
    • 몇 번을 살아남으면 Old 영역으로 이동한다.
  • Old 영역은 주로 Mark-Sweep-Compact 알고리즘으로 관리되고, 기본적으로는 Parallel GC가 적용된다.

 

 

 

728x90

'프로그래밍 > JAVA' 카테고리의 다른 글

synchronized  (0) 2025.04.03
volatile  (0) 2025.04.03
스레드 생명 주기  (0) 2025.04.03
스레드 생성과 실행  (0) 2025.04.03
List  (0) 2025.03.28

 

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

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

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

 

 

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 를 넣는다.
728x90

'프로그래밍 > JAVA' 카테고리의 다른 글

JVM, GC  (1) 2025.04.10
volatile  (0) 2025.04.03
스레드 생명 주기  (0) 2025.04.03
스레드 생성과 실행  (0) 2025.04.03
List  (0) 2025.03.28

 

메모리 가시성 문제

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

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

실제 메모리 접근 방식

  • 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 키워드를 붙이자.
  • 단, 캐시 메모리를 쓸 때보다는 성능이 느려지는 단점이 있기 때문에 꼭 필요한 곳에서만 사용해야 한다.
728x90

'프로그래밍 > JAVA' 카테고리의 다른 글

JVM, GC  (1) 2025.04.10
synchronized  (0) 2025.04.03
스레드 생명 주기  (0) 2025.04.03
스레드 생성과 실행  (0) 2025.04.03
List  (0) 2025.03.28

 

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

스레드 생명 주기

 

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

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 가 된다.
  • 스레드가 종료되면 다시 시작할 수 없다.
728x90

'프로그래밍 > JAVA' 카테고리의 다른 글

synchronized  (0) 2025.04.03
volatile  (0) 2025.04.03
스레드 생성과 실행  (0) 2025.04.03
List  (0) 2025.03.28
스레드 생성하기  (0) 2025.03.28

 

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() 를 호출해야 스택 공간을 할당 받고 스레드가 작동한다.
  • 스레드는 순서와 실행 기간을 모두 보장하지 않는다! 이것이 멀티스레드다.
728x90

'프로그래밍 > JAVA' 카테고리의 다른 글

volatile  (0) 2025.04.03
스레드 생명 주기  (0) 2025.04.03
List  (0) 2025.03.28
스레드 생성하기  (0) 2025.03.28
Exception  (0) 2025.03.20

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

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

 

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

  ArrayList LinkedList
인덱스 조회 O(1) O(n)
데이터로 검색 O(n) O(n)
앞에 추가/삭제 O(n) O(1)
뒤에 추가/삭제 O(1) O(n)
평균 추가/삭제 O(n) O(n)

ArrayList 배열리스트

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

LinkedList 연결리스트

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

'프로그래밍 > JAVA' 카테고리의 다른 글

스레드 생명 주기  (0) 2025.04.03
스레드 생성과 실행  (0) 2025.04.03
스레드 생성하기  (0) 2025.03.28
Exception  (0) 2025.03.20
String 클래스  (1) 2025.03.20

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 객체를 공유할 수 있어 자원 관리를 효율적으로 할 수 있다!
728x90

'프로그래밍 > JAVA' 카테고리의 다른 글

스레드 생성과 실행  (0) 2025.04.03
List  (0) 2025.03.28
Exception  (0) 2025.03.20
String 클래스  (1) 2025.03.20
자바 객체 지향  (0) 2025.03.13

목차

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 강의를 듣고 요약한 내용입니다. 

728x90

'프로그래밍 > JAVA' 카테고리의 다른 글

List  (0) 2025.03.28
스레드 생성하기  (0) 2025.03.28
String 클래스  (1) 2025.03.20
자바 객체 지향  (0) 2025.03.13
자바 기본1  (0) 2025.03.13

목차 

1. String 클래스 구조 

2. String 클래스가 불변 객체인 이유 

3. StringBuilder

4. StringBuffer


1. String 클래스 구조

  • java 17 기준으로 String 클래스 구현 코드를 열어봤다.
  • 문자열은 문자 배열 byte[] 로 저장된다. 

 

(안 중요 하니까 참고) java9 부터 내부 구현을 char[] 에서 byte[] 로 저장하도록 바뀌었다고 한다. 

  • char 타입은 2byte 이다.
  • 그런데 보통 문자열로 저장되는 영어와 숫자는 1byte 단위로 메모리를 채운다.
    • 문자열이 단순 영어, 숫자로만 표현된 경우, 1byte 단위로 사용하게 된다.
    • 그렇지 않은 나머지의 문자의 경우는 2byte 인 UTF-16 인코딩을 사용한다.

-> 1byte 단위로 다루어서 메모리를 더 효율적으로 사용하도록 개선된 것이다. 

 

2. String 클래스가 불변 객체인 이유 

  • String 의 value는 자바 메모리 영역 중에 Method Area 메서드 영역에 저장된다. 
  • 메서드 영역 내에 문자열 상수 풀이 있다. String Constant Pool
  • 컴파일러는 문자열 리터럴을 컴파일 타임에 미리 최적화 해둔다. 
    • String Pool에 "hello" 라는 리터럴을 저장해뒀다고 하자. 이 값을 여러 인스턴스들이 같이 참조하고 있다.
    • "hello" -> "bye" 로 바뀐다면, 해당 값을 참조하고 있는 다른 인스턴스들도 영향을 받게된다!
  • String 클래스가 불변 객체이기 때문에 여러 객체가 동일한 문자열을 공유할 수 있고, 메모리 효율성을 높일 수 있다.

 

3. StringBuilder

  • 문자열 편집이 빈번한 경우, 대부분 StringBuilder 를 쓰게 된다. 
  • String 은 불변 객체라 값을 자주 바꾸면 너무 많은 인스턴스가 heap 메모리를 차지하게 되버린다. 
    • 연산 과정에서 쓰인 String 인스턴스는 GC의 대상이 된다. 
  • 문자열 편집이 끝나면 불변인 String 으로 변환해두자

StringBuilder 사용이 더 나은 경우 

  • 런타임에 편집 횟수가 정해지는 경우 (몇 만번 ..)
  • 조건문을 통해 런타임에 동적으로 문자열을 편집해야 하는 경우 
  • 매우 긴 문자열을 다룰 때 

 

4. StringBuffer

  • StringBuilder 와 StringBuffer 는 똑같은 기능을 제공한다. 
  • (멀티스레드 관련 내용이라 완전히 이해하지는 못했고 공부중이다.)
  • StringBuffer 는 멀티스레드 상황에서 안전하지만, 동기화 오버헤드로 속도가 느리다. 
  • StringBuilder는 멀티스레드 상황에서 안전하지 않지만, 동기화 오버헤드가 없으므로 비교적 속도가 빠르다.
728x90

'프로그래밍 > JAVA' 카테고리의 다른 글

List  (0) 2025.03.28
스레드 생성하기  (0) 2025.03.28
Exception  (0) 2025.03.20
자바 객체 지향  (0) 2025.03.13
자바 기본1  (0) 2025.03.13

+ Recent posts