• 여러 선택지중에 하나를 고르는 경우 => 더하기 ( 이거 또는 저거) ex) 학교를 가야 하는데 버스를 타는 경우 3가지 지하철 타는 경우 2가지. => 하나를 골라야함. 3 + 2

• 여러 선택지중에 동시에 고르는 경우 => 곱하기 ( 이거 그리고 저거) ex) 메뉴를 골라야 하는데 메뉴 3가지 음료 2가지. => 동시에 골라야함. 3 * 2 만약 아무것도 안골라야 하는 상황도 있다면? 메뉴 3가지 + (아무것도안고름 + 1) 음료 2가지 + (아무것도안고름 + 1) => 4 * 3 다 아무것도 안고르는 경우는 없다면? => 4 * 3 - 1

dfs, bfs 개념 공부진행함.

String 에서 인덱스로 접근 하는 방법 => 문자열.chartAt(인덱스) Character 형식으로 변환함.

문자열 비교 할때, 대소문자 상관 없다면, 문자열이면 => 문자열.toUpperCase 문자이면 => Character.toUpperCase(문자) 이렇게 변환해서 사용.

문자열 대소문자 확인 하는 메소드 Character.isUpperCase(문자) Character.isLowerCase(문자)

아스키 코드로 풀어도됨. ( 아스키 코드) 아스키 소문자 65 ~ 90 이니까 + 32 하면 대,소문자 구분됨.

Scanner 에서 NextInt() 로 받으면, 버퍼가 남겨짐. 그래서 sc.NextInt() 후엔 sc.nextLine() 같은걸로 버퍼를 없애줘야함.

REST API는 HTTP 프로토콜 위에서 동작하는 웹 기반 데이터 통신 아키텍처 스타일입니다. 리소스(자원)를 URL로 식별하고, **HTTP 메서드(GET, POST 등)**를 통해 이를 조작합니다.

REST = REpresentational State Transfer 자원의 표현을 HTTP를 통해 전송하는 방식

🔧 REST API의 핵심 특징

• 프로토콜: HTTP 기반
• 형식: JSON을 주로 사용
• 자원 중심: URL로 자원을 명시적으로 표현
• 표준화된 동작: HTTP 메서드 사용

📦 HTTP 메서드 종류

🧪 REST API 예시

🔷 REST API의 6가지 설계 원칙

1. 클라이언트-서버 구조: 프론트와 백 분리
2. 무상태성(Stateless): 서버는 클라이언트 상태를 저장하지 않음
3. 캐시 가능: 응답은 명시적으로 캐시 가능
4. 계층 구조: 중간 계층(API Gateway 등) 허용
5. 일관된 인터페이스: URL + 메서드로 조작
6. 코드 온 디맨드(Optional): 서버가 코드 전달 가능 (거의 사용 안 함)

✅ REST API의 장점

• HTTP 표준을 활용 → 학습 비용 낮음
• JSON 사용 → 경량 통신
• 범용성 높음 → 웹, 앱, IoT 등에서 사용 가능
• 개발자 친화적 URL 구성

🔐 HTTP 상태 코드 자주 쓰는 것

🔧 REST API 사용 환경

❌ REST API가 아닌 기술들

WebSocket도 REST와는 전혀 다른 방식!

❓ 자주 묻는 질문 (FAQ)

🧭 마무리

• REST API는 현대 웹/앱 개발의 핵심 표준
• HTTP + 자원 중심 URL + 표준 메서드(GET, POST 등)
• JSON을 통해 가볍고 빠른 통신이 가능
• FastAPI, Spring Boot 등 다양한 프레임워크에서 쉽게 구현 가능

🧪 예제 코드 (FastAPI)

from fastapi import FastAPI

app = FastAPI()

@app.get("/users/{user_id}")
def get_user(user_id: int):
    return {"user_id": user_id, "name": "홍길동"}

🧪 예제 코드 (Spring Boot)

@RestController
@RequestMapping("/users")
public class UserController {
    @GetMapping("/{id}")
    public ResponseEntity<UserDto> getUser(@PathVariable Long id) {
        return ResponseEntity.ok(userService.findById(id));
    }
}

brandService.getBrandById를 호출하는 시점이 service단 @Transactional(readOnly = true) 환경에서 실행되고, 그 이후 컨트롤러에서 brand.getBranches()를 호출하는 순간에 세션이 닫혀 있으면 LazyInitializationException 발생함.

@Transactional의 역할은 → EntityManager (=영속성 컨텍스트 = 세션)를 열고 닫는 라이프사이클을 관리하는 것

상황 결과 @Transactional 안에서 Lazy 필드 접근 ✅ 정상 작동 @Transactional 밖에서 Lazy 필드 접근 ❌ LazyInitializationException 발생

brandService.getBrandById() 안에서는 service단) @Transactional(readOnly = true) 트랜잭션 안에서 실행됨 이건 OK 하지만, 그 이후 getBrandById()가 끝나고 나면 트랜잭션이 종료되고, EntityManager가 close됨. ( 컨트롤러나 그 이후 상황...) 이 상황에서 컨트롤러에서 brand.getBranches()를 호출하면 연관 데이터는 아직 DB에서 안 가져왔는데, 영속성 컨텍스트는 이미 사라짐. -> 즉, JPA가 데이터를 가져올 수 없음... -> LazyInitalizationException이 발생함.

결국 엔티티를 그대로 노출 하는건 위험하고 DTO 노출로 가야함. CRUD를 쓰는 Entity들은 다 DTO로 감싸서 보내야함.

• Lazy 문제를 방지함.
• 꼭 필요한 정보만 전달함. ( 프론트엔드에 맞춘 데이터 형식 가공 가능함.)
• 엔티티 직접 노출로부터 보호. ( 엔티티 수정시. 의도치 못한 버그 발생 가능함.)
• 계층 간 의존성 분리. 엔티티는 DB와 밀접한 구조 -> 리포지토리/도메인 계층 DTO는 view/API 전용 구조 -> 컨트롤러/프론트엔드용. ✅ 엔티티 구조가 바뀌어도 API 스펙을 바꾸지 않아도 됨 → 유지보수 용이 성능 최적화. ( select 쿼리 튜징쉬움 )

자바에서 파일, 네트워크 소켓, 데이터베이스 연결 같은 자원은 사용 후 반드시 정리(close) 해야 한다. 그렇지 않으면 메모리 누수(memory leak) 또는 리소스 잠금(locking issue) 같은 문제가 발생할 수 있다.

자원을 정리하는 일반적인 방법은 try-finally 를 사용하는 것이다. 하지만 예외 처리를 제대로 하지 않으면 예상치 못한 문제들이 발생할 수 있다.

2. 문제 상황

아래 코드는 두 개의 리소스를 생성하고, 하나의 메서드에서 호출하는 과정에서 예외가 발생할 경우를 다룬다.

package network.tcp.autocloseable;

public class ResourceCloseMainV2 {

    public static void main(String[] args) {
        try {
            logic();
        } catch (CallException e) {
            System.out.println("CallException 예외 처리");
            e.printStackTrace();
        } catch (CloseException e) {
            System.out.println("CloseException 예외 처리");
            e.printStackTrace();
        }
    }

    private static void logic() throws CallException, CloseException {
        ResourceV1 resource1 = null;
        ResourceV1 resource2 = null;

        try {
            resource1 = new ResourceV1("resource1");
            resource2 = new ResourceV1("resource2");
            resource1.call();
            resource2.callEx(); // CallException 발생
        } catch (CallException e) {
            System.out.println("ex: " + e);
            throw e; // CallException 다시 던짐
        } finally {
            if (resource2 != null) {
                resource2.closeEx(); // CloseException 발생
            }
            if (resource1 != null) {
                resource1.closeEx();
            }
        }
    }
}

이 코드에서 발생할 수 있는 주요 문제들을 살펴보자.

3. 문제점 분석

❌ 1. null 체크 문제

• finally 블록을 사용하면 예외가 발생해도 자원 정리 코드가 실행된다.
• 하지만, 객체를 생성하기 전에 예외가 발생하면 해당 객체는 null 이 된다.
• 따라서 null 체크를 하지 않으면 NullPointerException 이 발생할 수 있다.

❌ 2. 자원 정리 중 예외 발생 문제

• finally 블록에서 closeEx() 메서드를 호출하는데, 이 과정에서 예외가 발생하면 그 이후 코드가 실행되지 않는다.
• 즉, 하나의 리소스 정리 중 예외가 발생하면 다른 리소스는 정리되지 못할 수 있다.

❌ 3. 핵심 예외(CallException)가 사라짐

• 코드의 핵심 예외는 callEx()에서 발생한 CallException이다.
• 하지만 finally 블록에서 추가로 CloseException이 발생하면 핵심 예외가 덮어씌워지는 문제가 발생할 수 있다.
• 최초 발생한 예외가 유지되지 않으면 디버깅이 어렵다.

4. 해결 방법

✅ 1. try-with-resources 사용 (권장)

• AutoCloseable을 구현하면 try-with-resources 문법을 활용할 수 있다.
• 자원 정리 과정에서 발생하는 예외를 자동으로 관리하고, null 체크도 필요 없다.

public class ResourceCloseMainV3 {
    public static void main(String[] args) {
        try (ResourceV1 resource1 = new ResourceV1("resource1");
             ResourceV1 resource2 = new ResourceV1("resource2")) {
            resource1.call();
            resource2.callEx(); // CallException 발생
        } catch (CallException e) {
            System.out.println("CallException 예외 처리");
            e.printStackTrace();
        } catch (CloseException e) {
            System.out.println("CloseException 예외 처리");
            e.printStackTrace();
        }
    }
}

✅ 2. suppressed 예외 활용하기

• try-with-resources는 리소스 정리 중 발생한 예외를 억제(suppressed)하여 관리할 수 있다.
• getSuppressed()를 사용하면 숨겨진 예외를 확인할 수 있다.

catch (Exception e) {
    Throwable[] suppressed = e.getSuppressed();
    for (Throwable t : suppressed) {
        t.printStackTrace();
    }
}

✅ 3. finally 블록에서 여러 개의 예외를 안전하게 처리하기

• try-catch를 추가하여 한 리소스의 정리 실패가 다른 리소스 정리에 영향을 주지 않도록 한다.

finally {
    try {
        if (resource2 != null) resource2.closeEx();
    } catch (Exception e) {
        e.printStackTrace();
    }
    try {
        if (resource1 != null) resource1.closeEx();
    } catch (Exception e) {
        e.printStackTrace();
    }
}

5. 정리

✅ try-with-resources를 사용하면 자원 정리가 자동화되고, 예외 처리도 안전하게 관리 가능

✅ getSuppressed()로 숨겨진 예외까지 추적 가능

✅ finally 블록에서 여러 개의 자원을 정리할 때는 개별 try-catch를 사용하여 다른 자원의 정리 실패를 방지해야 함

자원 관리를 안전하게 처리하는 것은 안정적인 애플리케이션 개발의 핵심이다. try-with-resources와 적절한 예외 처리를 활용하여 더 견고한 코드를 작성하자! 🚀

네트워크 통신에서 서버와 통신하려면 IP 주소가 필요하다. 도메인(호스트 이름)만으로는 통신할 수 없으며, 도메인을 실제 IP 주소로 변환해야 한다.

자바에서는 InetAddress 클래스를 사용하여 도메인 이름을 IP 주소로 변환할 수 있다.

import java.net.*;

public class HostToIP {
    public static void main(String[] args) {
        try {
            InetAddress address = InetAddress.getByName("www.google.com");
            System.out.println("IP Address: " + address.getHostAddress());
        } catch (UnknownHostException e) {
            e.printStackTrace();
        }
    }
}

2. 서버와 클라이언트의 데이터 송수신

InputStream과 OutputStream

소켓 통신에서 데이터를 주고받을 때 InputStream과 OutputStream을 사용한다.

• InputStream: 서버 -> 클라이언트로 데이터를 받을 때 사용
• OutputStream: 클라이언트 -> 서버로 데이터를 보낼 때 사용

하지만, 기본 스트림을 그대로 사용하면 byte 단위로 데이터를 변환해야 하는 불편함이 있다. 이를 해결하기 위해 보조 스트림을 사용한다.

DataInputStream과 DataOutputStream

DataInputStream과 DataOutputStream을 사용하면 자바 기본 타입(int, float, String 등) 을 편리하게 송수신할 수 있다.

import java.io.*;
import java.net.*;

public class Client {
    public static void main(String[] args) {
        try (Socket socket = new Socket("localhost", 12345);
             DataOutputStream dos = new DataOutputStream(socket.getOutputStream());
             DataInputStream dis = new DataInputStream(socket.getInputStream())) {

            dos.writeUTF("Hello Server"); // 문자열 전송
            System.out.println("Server response: " + dis.readUTF()); // 응답 수신
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

3. 서버 소켓과 클라이언트 소켓

서버 소켓의 역할

서버는 특정 포트를 열어두어야 클라이언트가 접속할 수 있다.

• ServerSocket: 클라이언트의 요청을 받아들여 연결만 담당하는 특별한 소켓
• Socket: 서버와 클라이언트가 데이터를 주고받을 수 있는 실제 통신 소켓

TCP 3-Way Handshake 과정

1. 클라이언트가 서버의 포트(예: 12345)로 연결 요청 (SYN)
2. 서버가 요청을 받아 승인 (SYN-ACK)
3. 클라이언트가 승인 확인 (ACK)
4. 연결 완료 → Backlog Queue에 TCP 연결 정보 저장

서버의 동작 과정

1. ServerSocket을 생성하고 특정 포트(예: 12345)에서 대기
2. accept()를 호출하여 클라이언트 요청을 대기
3. 클라이언트가 연결하면 새로운 Socket 객체를 생성하여 통신

import java.io.*;
import java.net.*;

public class Server {
    public static void main(String[] args) {
        try (ServerSocket serverSocket = new ServerSocket(12345)) {
            System.out.println("서버 대기 중...");

            while (true) {
                Socket socket = serverSocket.accept(); // 클라이언트 연결 대기 (블로킹)
                System.out.println("클라이언트 연결 완료!");

                new Thread(new ClientHandler(socket)).start();
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

class ClientHandler implements Runnable {
    private Socket socket;

    public ClientHandler(Socket socket) {
        this.socket = socket;
    }

    @Override
    public void run() {
        try (DataInputStream dis = new DataInputStream(socket.getInputStream());
             DataOutputStream dos = new DataOutputStream(socket.getOutputStream())) {

            String message = dis.readUTF(); // 클라이언트 메시지 수신
            System.out.println("Received: " + message);
            dos.writeUTF("Hello Client!"); // 응답 전송
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

4. 블로킹과 멀티스레드 처리

accept()의 블로킹 문제

• accept() 메서드는 클라이언트 연결 요청이 없으면 무한 대기 상태(블로킹)가 된다.
• readUTF() 같은 입력 메서드도 데이터를 받을 때까지 대기 상태가 된다.
• 따라서, 서버는 멀티스레드 방식으로 각각의 클라이언트 요청을 별도의 스레드에서 처리해야 한다.

멀티스레드 방식의 서버

각 클라이언트가 연결될 때마다 새로운 Thread를 생성하여 별도로 처리하면, 여러 클라이언트를 동시에 처리할 수 있다.

• 메인 스레드: ServerSocket을 관리하고 새로운 연결이 올 때마다 Session 스레드를 생성
• Session 스레드: 특정 클라이언트와 1:1로 데이터를 주고받는 역할

5. 정리

✅ 서버 소켓과 클라이언트 소켓

• ServerSocket은 연결만 담당하는 특별한 소켓
• 실제 데이터 송수신은 Socket 객체를 통해 이루어짐

✅ TCP 연결 과정

• 클라이언트가 connect() 요청하면 TCP 3-Way Handshake 후 Backlog Queue에 저장
• accept() 호출 시 Socket 객체 생성 후 클라이언트와 통신 가능

✅ 스트림을 이용한 데이터 송수신

• DataInputStream / DataOutputStream을 활용하면 편리한 데이터 송수신 가능

✅ 멀티스레드 처리 필요

• accept()와 readUTF() 같은 블로킹 메서드는 별도 스레드에서 실행해야 함

이제 자바 소켓 프로그래밍에 대한 기본 개념을 정리했으니, 실전 프로젝트에서 활용해 보자! 🚀

1. 입력 스트림과 버퍼의 기본 원리

자바에서 read() 메소드를 사용할 때, 미리 생성된 byte[] 버퍼를 전달하여 한 번에 여러 바이트를 읽어올 수 있습니다.

• byte[] 버퍼: 데이터를 임시로 저장하는 공간입니다.
• offset: 버퍼에서 데이터를 기록하기 시작할 인덱스입니다.
• length: 읽어올 최대 바이트 수를 지정합니다.

현대 컴퓨터는 바이트 단위로 데이터를 주고받으며, 스트림을 사용하면 파일 I/O, 네트워크 통신 등 다양한 데이터 전송 방식을 동일한 방식으로 다룰 수 있습니다.

참고: read()와 write() 메소드가 호출될 때마다 OS의 시스템 콜이 발생하는데, 시스템 콜은 상대적으로 무거운 작업입니다. HDD나 SDD와 같은 저장 장치에서도 한 바이트씩 처리하면 성능에 큰 영향을 주므로, 버퍼를 활용하여 여러 바이트를 한 번에 처리하는 것이 효율적입니다.

2. 버퍼 사용의 중요성

2.1 버퍼의 역할

• 시스템 콜 최소화:
  한 번에 많은 데이터를 전달하면 시스템 콜 호출 횟수가 줄어들어 성능이 향상됩니다.

• 하드웨어 최적화:
  실제 디스크나 파일 시스템은 보통 4KB 또는 8KB 단위로 데이터를 읽고 쓰므로, 이보다 작은 단위로 데이터를 다루면 불필요한 오버헤드가 발생합니다.

2.2 BufferedXXX 클래스

자바에서는 기본 스트림(예: FileOutputStream, FileInputStream) 외에도, 보조 스트림으로서 BufferedOutputStream과 BufferedInputStream을 제공하여 버퍼 기능을 쉽게 사용할 수 있습니다.

• BufferedOutputStream:
  내부적으로 버퍼를 사용하여 데이터를 모았다가 한 번에 출력 스트림에 전달합니다.

  주의: 반드시 대상 스트림(예: FileOutputStream)이 필요합니다.

• BufferedInputStream:
  미리 정해진 버퍼 크기만큼 데이터를 읽어와 저장해두고, 이후 read() 호출 시 버퍼에서 데이터를 반환하여 성능을 개선합니다.

3. 성능 최적화 전략

• 작은 파일 처리:
  파일의 크기가 작아 메모리 부담이 적다면, 전체 파일을 한 번에 처리하는 것도 좋은 선택입니다.

• 큰 파일 또는 성능이 중요한 경우:
  파일이 크거나 성능이 중요한 경우, 버퍼 크기를 적절히 조절하여 파일을 나누어 처리하는 것이 좋습니다.

• 동기화 비용 고려:
  BufferedXXX 클래스는 내부에 동기화 코드를 포함하고 있으므로, 멀티스레드 환경에서의 안전성을 제공하지만 단일 스레드 환경에서는 오버헤드가 발생할 수 있습니다.

4. 자바 코드 예제

다음 예제는 BufferedInputStream과 BufferedOutputStream을 사용하여 파일을 읽고 쓰는 과정을 보여줍니다.

import java.io.*;

public class BufferedFileCopy {
    public static void main(String[] args) {
        // 원본 파일과 대상 파일 경로 설정
        String inputFile = "input.txt";
        String outputFile = "output.txt";

        // 4KB 크기의 버퍼 사용 (파일 시스템의 기본 단위와 유사)
        byte[] buffer = new byte[4096];

        try (
            // 기본 스트림에 보조 스트림(버퍼 기능)을 추가
            BufferedInputStream bis = new BufferedInputStream(new FileInputStream(inputFile));
            BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream(outputFile))
        ) {
            int bytesRead;
            // 버퍼에 데이터를 읽어오면서 파일 전체를 복사
            while ((bytesRead = bis.read(buffer, 0, buffer.length)) != -1) {
                bos.write(buffer, 0, bytesRead);
            }
            // 버퍼에 남아있는 데이터를 출력 스트림에 완전히 전달
            bos.flush();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

컴퓨터가 데이터를 저장하는 기본 원리는 이진수(0과 1) 입니다. 컴퓨터 메모리는 수많은 전구처럼 작동하는 트랜지스터로 구성되어 있으며, 이 트랜지스터는 전류가 흐르거나 흐르지 않는 두 가지 상태를 표현합니다. 이와 같이, 모든 데이터는 결국 0과 1의 조합으로 저장됩니다.

1. 문자 인코딩과 디코딩

• 문자 인코딩 (Encoding):
  문자를 특정한 숫자(바이트)로 변환하는 과정입니다.
  예시: A → 65, B → 66

• 문자 디코딩 (Decoding):
  인코딩된 숫자(바이트)를 원래의 문자로 변환하는 과정입니다.

프로그래밍 언어에서 문자열을 바이트로 변환할 때는 항상 문자 집합(Charset) 을 명시해야 합니다. 예를 들어, 자바에서는 String.getBytes(Charset charset) 메소드를 사용하여 인코딩할 수 있습니다.

2. 아스키(ASCII) 코드와 UTF-8

아스키(ASCII) 문자 집합

• 정의:
  아스키 코드는 128개의 문자(0~127)를 표현할 수 있는 인코딩 방식입니다.
• 용도:
  주로 영어 알파벳, 숫자, 기본 구두점 등을 다룹니다.

UTF-8 인코딩

• 특징:
  • 가변 길이 인코딩: 1바이트부터 최대 4바이트까지 사용하여 문자를 표현합니다.
  • 아스키와 호환: 아스키 범위(0~127)의 문자는 UTF-8에서도 동일한 바이트 값을 사용합니다.
• 효율성:
  • 저장 공간 절약: 대부분의 서양 문자와 ASCii 문자는 1바이트만 사용합니다.
  • 네트워크 효율성: 영문 텍스트를 전송할 때 UTF-8은 UTF-16보다 최대 2배 더 효율적입니다.
    참고로 웹상의 문서 중 80% 이상이 영문이므로, UTF-8의 효율성은 매우 중요합니다.

3. 실무에서의 문자 인코딩 활용

문자 집합 선택

문자열을 바이트로 변환할 때는 반드시 사용할 문자 집합(예: UTF-8, EUC-KR, ISO-8859-1)을 지정해야 합니다. 잘못된 문자 집합을 사용할 경우, 특히 한글과 같이 다국어 문자의 경우 문자 깨짐(garbled text) 문제가 발생할 수 있습니다.

한글 깨짐 문제의 주요 원인

1. EUC-KR과 UTF-8의 호환성 문제:
   UTF-8로 인코딩한 한글을 EUC-KR(ms949)로 디코딩하거나, 반대로 EUC-KR로 인코딩한 한글을 UTF-8로 디코딩할 때 문제가 발생합니다.

2. ISO-8859-1과의 혼용:
   EUC-KR이나 UTF-8로 인코딩한 한글을 ISO-8859-1로 디코딩하면, 지원하지 않는 문자로 인해 깨짐 현상이 발생합니다.

예시

package charset;

import java.nio.charset.Charset;
import java.util.Arrays;

import static java.nio.charset.StandardCharsets.*;

public class EncodingMain2 {

    private static final Charset EUC_KR = Charset.forName("EUC-KR");
    private static final Charset MS_949 = Charset.forName("MS949");


    public static void main(String[] args) {
        System.out.println("== 영문 ASCII 인코딩 ==");
        test("A", US_ASCII, US_ASCII);
        test("A", US_ASCII, ISO_8859_1); // ASCII 확장(LATIN-1)
        test("A", US_ASCII, EUC_KR); // ASCII 포함
        test("A", US_ASCII, MS_949); // ASCII 포함
        test("A", US_ASCII, UTF_8); // ASCII 포함
        test("A", US_ASCII, UTF_16BE); // UTF_16 디코딩 실패


        System.out.println("== 한글 인코딩 - 기본 ==");
        test("가", US_ASCII, US_ASCII); // X
        test("가", ISO_8859_1, ISO_8859_1); // X
        test("가", EUC_KR, EUC_KR);
        test("가", MS_949, MS_949);
        test("가", UTF_8, UTF_8);
        test("가", UTF_16BE, UTF_16BE);


        System.out.println("== 한글 인코딩 - 복잡한 문자 ==");
        test("뷁", EUC_KR, EUC_KR); // X
        test("뷁", MS_949, MS_949);
        test("뷁", UTF_8, UTF_8);
        test("뷁", UTF_16BE, UTF_16BE);


        System.out.println("== 한글 인코딩 - 디코딩이 다른 경우 ==");
        test("가", EUC_KR, MS_949);
        test("뷁", MS_949, EUC_KR); // 인코딩 가능, 디코딩 X
        test("가", EUC_KR, UTF_8); // X
        test("가", MS_949, UTF_8); // X
        test("가", UTF_8, MS_949); // X


        System.out.println("== 영문 인코딩 - 디코딩이 다른 경우 ==");
        test("A", EUC_KR, UTF_8);
        test("A", MS_949, UTF_8);
        test("A", UTF_8, MS_949);
        test("A", UTF_8, UTF_16BE); // X
    }



    private static void test(String text, Charset encodingCharset, Charset decodingCharset){
        byte[] encoded = text.getBytes(encodingCharset);
        String decoded = new String(encoded, decodingCharset);
        System.out.printf("%s -> [%s] 인코딩 -> %s %sbyte -> [%s] 디코딩 -> %s\n",
                text, encodingCharset, Arrays.toString(encoded),
                encoded.length,
                decodingCharset, decoded);


    }


}

목차

• 1. 스레드 생성 비용과 성능 문제
• 2. Runnable 인터페이스의 불편함
• 3. ThreadPoolExecutor와 Future의 등장
• 4. Future.get() 호출과 Blocking/Non-Blocking
• 5. 작업 취소: cancel() 메서드의 활용
• 6. 추가적인 팁과 고려사항
• 결론

1. 스레드 생성 비용과 성능 문제

스레드를 직접 생성할 경우,

• 메모리 할당: 새로운 스레드를 위한 스택 메모리 할당
• 운영체제 자원 사용: 스레드 관리를 위한 커널 자원 사용
• 스케줄러 설정: OS의 스케줄러가 각 스레드를 관리하도록 해야 함

이런 작업들은 상당한 비용을 수반합니다. 특히, 많은 작업을 짧은 시간 내에 처리해야 하는 경우라면
스레드 생성 및 소멸에 드는 오버헤드가 전체 성능 저하로 이어질 수 있습니다.

예시: 다수의 작업을 순차적으로 처리하는 경우, 작업마다 새로운 스레드를 생성하면 매번 OS에 부담을 주게 됩니다.

2. Runnable 인터페이스의 불편함

자바에서 스레드를 구현할 때 흔히 사용되는 Runnable 인터페이스는 다음과 같은 한계가 있습니다.

• 반환 값이 없음: Runnable의 run() 메서드는 실행 결과를 반환하지 않으므로, 작업 결과를 외부에서 직접 받아볼 수 없습니다.
• 결과 전달 방식의 번거로움: 실행 결과를 별도의 멤버 변수에 저장한 후, join() 등을 통해 스레드가 종료되길 기다려야 합니다.

이러한 한계를 극복하기 위해 등장한 것이 Callable 인터페이스입니다.
Callable은 결과를 반환할 수 있으며 예외 처리도 보다 유연하게 할 수 있습니다.

Runnable 예시:

public class MyRunnable implements Runnable {
    @Override
    public void run() {
        // 작업 수행
        System.out.println("Runnable 작업 수행");
    }
}

Callable 예시:

public class MyCallable implements Callable<Integer> {
    @Override
    public Integer call() {
        // 작업 수행 후 결과 반환
        return 42;
    }
}

3. ThreadPoolExecutor와 Future의 등장

스레드 생성 비용 문제와 Runnable의 한계를 보완하기 위해 ThreadPoolExecutor를 사용합니다.
ThreadPoolExecutor는 요청이 들어올 때마다 새로운 스레드를 생성하는 대신, 미리 생성된 스레드 풀을 활용해 작업을 할당합니다.

• 스레드 풀의 장점:
  • 스레드 생성 오버헤드 감소
  • 재사용 가능한 스레드로 효율적인 자원 관리
  • 작업 큐를 통한 작업 관리

또한, submit() 메서드를 사용하면 Future 객체가 즉시 반환되어 요청 스레드가 블로킹되지 않습니다.

예시:

ExecutorService executor = Executors.newFixedThreadPool(5);
Future<Integer> future = executor.submit(new MyCallable());
// 요청 스레드는 다른 작업을 수행할 수 있음.

4. Future.get() 호출과 Blocking/Non-Blocking

Future 객체는 제출된 작업의 미래 결과를 나타냅니다.
Future.get() 메서드를 호출하면 두 가지 상황이 발생할 수 있습니다:

1. 작업이 완료된 경우
   • Future 내부에 작업 결과가 존재하므로, 즉시 반환됩니다.
2. 작업이 아직 완료되지 않은 경우
   • Future는 결과가 준비될 때까지 요청 스레드를 블로킹 상태로 만듭니다.

이러한 동작 덕분에 요청 스레드는 작업 결과가 필요한 시점에만 기다리게 되어,
비동기적으로 작업을 수행하면서도 결과를 적시에 받을 수 있습니다.

예시:

// 비동기적으로 두 작업을 제출
Future<Integer> future1 = executor.submit(task1);
Future<Integer> future2 = executor.submit(task2);

// 필요 시 결과를 블로킹 호출로 받아올 수 있음
Integer result1 = future1.get();
Integer result2 = future2.get();

5. 작업 취소: cancel() 메서드의 활용

Future는 아직 완료되지 않은 작업을 취소할 수 있는 기능도 제공합니다.
cancel(boolean mayInterruptIfRunning) 메서드는 다음과 같이 동작합니다:

• cancel(true):
  • Future를 취소 상태로 변경하고, 만약 작업이 실행 중이라면 Thread.interrupt()를 호출하여 중단시킵니다.
• cancel(false):
  • Future를 취소 상태로 변경하지만, 실행 중인 작업은 중단시키지 않습니다.

이러한 기능을 통해 필요 없는 작업에 대한 자원 낭비를 방지할 수 있습니다.

예시:

// 작업 취소 예제
if (!future.isDone()) {
    future.cancel(true); // 실행 중인 작업이라도 중단을 시도
}

6. 추가적인 팁과 고려사항

• 예외 처리: Future의 get() 메서드 호출 시 InterruptedException과 ExecutionException에 대한 처리가 필요합니다.
  예외 상황에 대비하여 적절한 로그 기록이나 리트라이 로직을 구현하세요.

• 스레드 풀 사이즈: 애플리케이션의 특성에 맞춰 스레드 풀의 크기를 조정하세요.
  너무 작은 풀은 작업 대기열이 쌓일 수 있고, 너무 큰 풀은 자원 낭비를 초래할 수 있습니다.

• 자원 정리: ExecutorService 사용 후에는 shutdown() 또는 shutdownNow()를 호출해 스레드 풀을 적절히 종료하는 것이 좋습니다.

• 실시간 모니터링: 운영 중인 스레드 풀의 상태를 모니터링하여, 필요 시 동적으로 스레드 수를 조정하거나 문제를 사전에 파악할 수 있도록 하세요.

결론

스레드 생성 비용으로 인한 성능 문제와 Runnable 인터페이스의 한계를 극복하기 위해,
자바에서는 ThreadPoolExecutor와 Future를 통한 비동기 처리 기법을 제공합니다.
이를 통해 불필요한 스레드 생성 오버헤드를 줄이고,
요청 스레드가 필요할 때만 결과를 블로킹하여 받아올 수 있는 유연한 구조를 구현할 수 있습니다.

1. 생산자-소비자 문제란?

생산자(Producer)와 소비자(Consumer)가 한정된 버퍼(Buffer)를 통해 데이터를 주고받는 상황을 가정합니다.

• 생산자(Producer): 데이터를 생성하여 버퍼에 저장하는 역할.
• 소비자(Consumer): 버퍼에서 데이터를 가져와 사용하는 역할.
• 버퍼(Buffer): 생산자가 생성한 데이터를 일시적으로 저장하는 공간. 크기가 제한됨.

문제 상황

• 생산자가 너무 빠름 → 버퍼가 가득 차면 더 이상 데이터를 넣을 수 없음.
• 소비자가 너무 빠름 → 버퍼가 비어있으면 소비할 데이터가 없음.

이를 해결하기 위해 생산자는 버퍼가 가득 찼을 때 대기, 소비자는 버퍼가 비었을 때 대기해야 합니다.

2. 한정된 버퍼 문제 (Bounded-Buffer Problem)

생산자-소비자 문제는 결국 버퍼의 크기가 제한되어 있기 때문에 발생합니다. 이를 해결하기 위해 스레드 동기화(Synchronization)가 필요합니다.

3. 해결 방법: wait()와 notify() 사용

자바에서는 wait()과 notify()를 사용하여 이 문제를 해결할 수 있습니다.

wait() 메서드

• 현재 스레드가 가진 락(Lock)을 반납하고 대기.
• synchronized 블록 안에서만 호출 가능.
• 다른 스레드가 notify()를 호출하면 다시 실행됨.

notify() 메서드

• wait() 상태에서 대기 중인 스레드 중 하나를 깨움.
• synchronized 블록 안에서 호출해야 함.

notifyAll() 메서드

• wait() 상태에서 대기 중인 모든 스레드를 깨움.

4. 구현 코드 (Java)

아래는 wait()와 notify()를 사용하여 생산자가 버퍼가 가득 찼을 때 대기하고, 소비자가 버퍼가 비었을 때 대기하는 코드입니다.

package thread.bounded;

import java.util.ArrayDeque;
import java.util.Queue;

import static util.MyLogger.log;

public class BoundedQueueV3 implements BoundedQueue {

    private final Queue<String> queue = new ArrayDeque<>();
    private final int max;

    public BoundedQueueV3(int max) {
        this.max = max;
    }

    @Override
    public synchronized void put(String data) {
        while (queue.size() == max) {
            log("[put] 큐가 가득 참. 생산자 대기");
            try {
                wait(); // 큐가 가득 찼으므로 대기
                log("[put] 생산자 깨어남");
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }
        queue.offer(data);
        log("[put] 생산자 데이터 저장, notify() 호출");
        notify(); // 대기 중인 소비자 깨움
    }

    @Override
    public synchronized String take() {
        while (queue.isEmpty()) {
            log("[take] 큐에 데이터가 없음, 소비자 대기");
            try {
                wait(); // 큐가 비었으므로 대기
                log("[take] 소비자 깨어남");
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }
        String data = queue.poll();
        log("[take] 소비자 데이터 획득, notify() 호출");
        notify(); // 대기 중인 생산자 깨움
        return data;
    }

    @Override
    public String toString() {
        return queue.toString();
    }
}

5. 코드 설명

1) 생산자 (put 메서드)

• synchronized를 사용하여 동기화.
• 큐가 가득 차면 wait()을 호출하여 락을 반납하고 대기.
• 빈 공간이 생기면 notify()를 호출하여 대기 중인 소비자를 깨움.

2) 소비자 (take 메서드)

• synchronized를 사용하여 동기화.
• 큐가 비어있으면 wait()을 호출하여 락을 반납하고 대기.
• 데이터가 들어오면 notify()를 호출하여 대기 중인 생산자를 깨움.

6. 실행 흐름

1. 생산자 스레드가 데이터를 넣으려 하지만 버퍼가 가득 차면 대기 (wait()).
2. 소비자가 데이터를 가져가면 생산자에게 공간이 생겼다고 알림 (notify()).
3. 소비자 스레드는 데이터를 가져가려 하지만 버퍼가 비어 있으면 대기 (wait()).
4. 생산자가 새로운 데이터를 넣으면 소비자에게 데이터를 사용할 수 있다고 알림 (notify()).

7. 결론

• wait()와 notify()를 사용하면 생산자-소비자 문제를 효과적으로 해결할 수 있다.
• 스레드가 필요할 때만 대기하고, 필요할 때만 실행되므로 성능이 향상된다.
• synchronized 블록 내에서 wait()와 notify()를 사용해야 한다.

이렇게 하면 생산자가 데이터를 버리거나, 소비자가 빈 데이터를 가져가는 문제를 해결할 수 있습니다! 🚀

🔒 synchronized의 단점

1️⃣ 무한 대기 (Blocked 상태)

synchronized를 사용하면, 스레드가 락을 획득하지 못할 경우 무한 대기하게 됩니다. 즉, 락이 풀릴 때까지 계속 기다려야 하며 다음과 같은 기능이 없습니다.

• 특정 시간까지만 대기하는 타임아웃 기능❌
• 중간에 다른 스레드가 강제로 깨우는 인터럽트 기능❌

이러한 문제 때문에 스레드가 영원히 실행되지 못하는 상황이 발생할 수도 있습니다.

2️⃣ 공정성 문제

락이 풀렸을 때 어떤 스레드가 락을 획득할지 보장되지 않습니다. 여러 개의 스레드가 대기 중이라면 특정 스레드가 너무 오랫동안 락을 얻지 못할 수도 있음 (기아 현상 발생 가능).

➡️ 이러한 문제를 해결하기 위해 Lock 인터페이스와 ReentrantLock이 등장했습니다.

🔑 Lock과 LockSupport 활용

Lock 인터페이스는 synchronized와 다르게 객체 내부에 있는 모니터 락을 사용하지 않고, 별도로 락을 관리할 수 있습니다. 대표적인 구현체는 ReentrantLock입니다.

✅ Lock 선언 및 사용 방법

private final Lock lock = new ReentrantLock();

synchronized(this) 대신 lock.lock()을 사용하여 락을 획득합니다.

lock.lock();
try {
    // 임계 영역
} finally {
    lock.unlock(); // 반드시 unlock() 호출해야 함!
}

💡주의! lock.unlock()은 반드시 finally 블록에서 호출해야 합니다. 그래야 중간에 예외가 발생해도 락이 정상적으로 해제됨.

⚡ Lock의 대기 큐와 LockSupport

ReentrantLock 내부에는 대기 큐가 존재합니다. 락을 얻지 못한 스레드는 대기 큐에 저장되고 이후 락이 해제되면 차례로 깨워집니다.

✅ LockSupport 활용

자바에서 스레드를 대기 상태로 만들고 깨우는 기능은 LockSupport 클래스를 활용합니다.

LockSupport.park();

위 코드를 실행하면 스레드는 WAITING 상태가 됩니다.

LockSupport.unpark(thread);

외부에서 스레드를 깨울 수 있습니다.

🧐 Blocked vs Waiting vs Timed_Waiting

💡 synchronized에서는 Blocked 상태만 존재하지만, Lock을 사용하면 더 유연한 대기 방식이 가능함.

🔄 ReentrantLock 동작 방식

1️⃣ 스레드 t2가 락을 획득하지 못하면 Waiting 상태가 되고 대기 큐에 등록됨 (LockSupport.park() 호출됨).

2️⃣ t1이 락을 사용한 후 unlock()을 호출하면 대기 큐에서 대기 중인 스레드를 깨움 (LockSupport.unpark(thread) 호출됨).

3️⃣ t2는 Runnable 상태로 전환되고, 다시 락을 획득하려고 시도함.

➡️ 이렇게 하면 synchronized보다 더 정교하게 동기화를 제어할 수 있음.

✅ 정리

👉 synchronized는 간단하지만 제한적이고, Lock은 유연하지만 직접 관리해야 한다는 점이 다름!

🚀 결론

• synchronized는 기본적인 동기화에는 적합하지만 무한 대기, 공정성 문제가 있음.
• Lock (ReentrantLock)을 사용하면 더 유연한 락 제어가 가능하고 공정성도 보장할 수 있음.
• 하지만 lock.lock()을 사용한 경우 반드시 unlock()을 명시적으로 호출해야 함 (안 하면 교착 상태 발생 가능!).
• LockSupport를 활용하면 특정 스레드를 직접 깨울 수도 있음.

➡️ 따라서 복잡한 동기화가 필요한 경우 Lock을 적극적으로 활용하는 것이 좋음! 🚀

멀티스레드를 사용할 때 가장 주의해야 할 점은 여러 스레드가 공유 자원에 동시에 접근하는 것으로 인해 발생하는 동시성 문제입니다.

대표적인 공유 자원은 인스턴스 필드(멤버 변수)입니다. 만약 여러 스레드가 동시에 공유 자원을 읽고 수정한다면, 데이터 불일치나 예상치 못한 동작이 발생할 수 있습니다.

2. 예제 코드

아래는 은행 계좌에서 출금을 처리하는 BankAccountV1과 BankAccountV2 클래스입니다.

(1) 동시성 문제 발생 코드: BankAccountV1

public class BankAccountV1 implements BankAccount {
    private int balance;

    public BankAccountV1(int initialBalance) {
        this.balance = initialBalance;
    }

    @Override
    public boolean widthdraw(int amount) {
        log("거래 시작: " + getClass().getSimpleName());
        log("[검증 시작] 출금액: " + amount + ", 잔액: " + balance);
        if (balance < amount) {
            log("[검증 실패] 출금액: " + amount + ", 잔액: " + balance);
            return false;
        }
        log("[검증 완료] 출금액: " + amount + ", 잔액: " + balance);
        sleep(1000); // 출금 처리 시간
        balance = balance - amount;
        log("[출금 완료] 출금액: " + amount + ", 변경 잔액: " + balance);
        log("거래 종료");
        return true;
    }

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

(2) 문제 발생 시나리오

아래처럼 두 개의 스레드(t1, t2)가 동시에 출금을 시도하면 문제가 발생할 수 있습니다.

public static void main(String[] args) throws InterruptedException {
    BankAccount account = new BankAccountV1(1000);

    Thread t1 = new Thread(new WithdrawTask(account, 800), "t1");
    Thread t2 = new Thread(new WithdrawTask(account, 800), "t2");
    t1.start();
    t2.start();

    sleep(500);
    log("t1 state: " + t1.getState());
    log("t2 state: " + t2.getState());
    t1.join();
    t2.join();
    log("최종 잔액: " + account.getBalance());
}

(3) 문제 설명

1. t1과 t2가 거의 동시에 balance를 확인합니다. (balance = 1000)
2. t1은 800원을 출금하기 위해 검증을 통과합니다.
3. t2도 같은 시점에서 800원을 출금할 수 있다고 판단합니다.
4. t1이 출금을 완료하여 잔액이 200원이 됩니다.
5. t2도 출금을 시도하여 잔액이 -600원이 되어버립니다. ❌(비정상 동작)

3. 해결 방법: synchronized 키워드 사용

멀티스레드 환경에서 한 번에 하나의 스레드만 실행하도록 하려면 임계 영역(critical section)을 보호해야 합니다.

Java에서는 synchronized 키워드를 사용하여 공유 자원에 대한 동기화를 적용할 수 있습니다.

(1) 동기화 적용 코드: BankAccountV2

public class BankAccountV2 implements BankAccount {
    private int balance;

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

    @Override
    public synchronized boolean widthdraw(int amount) {
        log("거래 시작: " + getClass().getSimpleName());
        log("[검증 시작] 출금액: " + amount + ", 잔액: " + balance);
        if (balance < amount) {
            log("[검증 실패] 출금액: " + amount + ", 잔액: " + balance);
            return false;
        }
        log("[검증 완료] 출금액: " + amount + ", 잔액: " + balance);
        sleep(1000); // 출금 처리 시간
        balance = balance - amount;
        log("[출금 완료] 출금액: " + amount + ", 변경 잔액: " + balance);
        log("거래 종료");
        return true;
    }

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

(2) synchronized가 하는 일

• synchronized 키워드를 메서드에 추가하면 한 번에 하나의 스레드만 해당 메서드를 실행할 수 있습니다.
• 즉, widthdraw() 메서드가 실행 중이면 다른 스레드는 해당 메서드에 접근할 수 없습니다.
• 덕분에 balance 값이 변경되는 과정이 안전하게 보호됩니다.

(3) 동기화 적용 후 결과

• t1이 balance를 확인하고 출금을 시작하면, t2는 대기합니다.
• t1이 출금을 완료한 후 t2가 실행되므로, t2는 출금 불가(잔액 부족) 상태를 올바르게 인식합니다.
• 결과적으로 데이터 불일치 문제가 해결됩니다.

4. 정리

멀티스레드 환경에서 공유 자원에 대한 동기화는 필수입니다. synchronized를 사용하면 임계 영역을 보호하여 데이터 불일치를 방지할 수 있습니다. 🚀

김영한님의 강의를 참고해서 만들었습니다.

CPU는 매우 빠르게 연산을 수행하지만, 메모리 속도는 상대적으로 느립니다. 이 문제를 해결하기 위해 캐시 메모리(Cache Memory)가 사용됩니다.

🖥️ CPU와 메모리 구조

main 스레드 -> CPU 코어1 -> 캐시 메모리 -> 메인 메모리
work 스레드 -> CPU 코어2 -> 캐시 메모리 -> 메인 메모리

• 메인 메모리(RAM): 용량이 크지만 CPU 입장에서 거리가 멀고 속도가 느림
• 캐시 메모리(Cache Memory): CPU 가까이에 있으며 속도가 매우 빠름, 하지만 용량이 작고 가격이 비쌈

🔥 멀티 스레드에서의 문제: 메모리 가시성

🎭 runFlag 문제 상황

volatile boolean runFlag = true;

Thread mainThread = new Thread(() -> {
    runFlag = false;
});

Thread workThread = new Thread(() -> {
    while (runFlag) {
        // do something...
    }
});

위 코드에서 mainThread가 runFlag 값을 false로 변경해도, workThread에서는 여전히 true로 보일 수 있습니다. 왜 그럴까요?

🧠 캐시 메모리의 역할

각 스레드는 CPU 코어에서 실행되며, 코어는 캐시 메모리를 활용합니다. runFlag 값이 캐시 메모리에 저장되면, 각 코어는 자신의 캐시 값을 계속 사용하게 됩니다. 즉, mainThread가 runFlag = false;로 변경해도, workThread가 실행되는 CPU 코어의 캐시 메모리에는 반영되지 않을 수 있습니다.

🕵️‍♂️ 언제 메인 메모리에 반영될까?

이 부분은 CPU 설계 및 캐시 동기화 정책에 따라 다릅니다. 즉, 명확한 시점을 보장할 수 없습니다.

• 어떤 CPU에서는 즉시 반영될 수도 있고,
• 어떤 CPU에서는 한참 뒤에 반영될 수도 있습니다.

이런 메모리 가시성 문제를 해결하지 않으면, 멀티 스레드 프로그래밍에서 의도치 않은 동작이 발생할 수 있습니다.

🏆 해결 방법

✅ volatile 키워드 사용

volatile boolean runFlag = true;

• volatile을 사용하면 모든 스레드가 항상 메인 메모리 값을 읽고 씁니다.
• 즉, 캐시를 거치지 않기 때문에 변경된 값이 모든 스레드에 즉시 반영됩니다.

✅ synchronized 블록 사용

synchronized (this) {
    runFlag = false;
}

• synchronized를 사용하면 스레드 간 동기화가 보장됩니다.
• 하지만 성능이 저하될 수 있으므로 주의해야 합니다.

✅ Lock 사용

Lock lock = new ReentrantLock();
lock.lock();
try {
    runFlag = false;
} finally {
    lock.unlock();
}

• Lock을 사용하면 synchronized보다 유연한 동기화가 가능합니다.

📌 정리

• 멀티 스레드 환경에서는 메모리 가시성 문제가 발생할 수 있다.
• 캐시 메모리 때문에 스레드마다 다른 값을 볼 수도 있다.
• 메모리 가시성 문제를 해결하려면 volatile, synchronized, Lock 등을 활용해야 한다.

이제 멀티 스레드 프로그래밍을 할 때 메모리 가시성을 꼭 고려 하시길 바랍니다.!

Java에서 interrupt() 메서드를 사용하면 Waiting, Timed_Waiting 상태의 스레드를 직접 깨워 Runnable 상태로 만들 수 있다. 하지만 interrupt()를 호출한다고 해서 즉시 InterruptedException이 발생하는 것은 아니다. 오직 sleep(), wait(), join() 같은 인터럽트 예외를 던지는 메서드를 호출하거나 호출 중일 때만 예외가 발생한다.

예제 코드로 살펴보는 인터럽트

아래 여러 버전의 코드를 통해 스레드를 중단하는 다양한 방법을 확인해 보자.

1. volatile 플래그를 사용한 방법 (ThreadStopMainV1)

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

    @Override
    public void run() {
        while (runFlag) {
            log("작업중");
            sleep(3000);
        }
        log("자원 정리");
        log("작업 종료");
    }
}

• volatile 변수를 사용하여 스레드가 false를 감지하면 반복문을 종료하도록 설계했다.
• 하지만 이 방법은 sleep() 상태에서는 즉시 반응하지 않기 때문에 반응 속도가 느릴 수 있다.

2. interrupt()를 사용한 방법 (ThreadStopMainV2)

static class MyTask implements Runnable {
    @Override
    public void run() {
        try {
            while (true) {
                log("작업중");
                Thread.sleep(3000);
            }
        } catch (InterruptedException e) {
            log("인터럽트 발생: " + e.getMessage());
        }
        log("자원 정리");
        log("작업 종료");
    }
}

• interrupt()를 사용하면 sleep()이 실행 중일 때 즉시 InterruptedException이 발생하여 종료된다.
• 하지만 인터럽트 상태는 자동으로 초기화(false) 된다.

3. isInterrupted()를 사용한 방법 (ThreadStopMainV3)

static class MyTask implements Runnable {
    @Override
    public void run() {
        while (!Thread.currentThread().isInterrupted()) {
            log("작업중");
        }
        try {
            log("자원 정리 시도");
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            log("자원 정리 실패 - 인터럽트 발생");
        }
        log("작업 종료");
    }
}

• isInterrupted()는 단순히 인터럽트 상태를 확인하는 역할을 한다. (초기화 X)
• 하지만 sleep() 호출 시 다시 InterruptedException이 발생하면, 한번 더 예외 처리가 필요하다.

4. Thread.interrupted()를 사용한 방법 (ThreadStopMainV4)

static class MyTask implements Runnable {
    @Override
    public void run() {
        while (!Thread.interrupted()) {
            log("작업중");
        }
        try {
            log("자원 정리 시도");
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            log("자원 정리 실패 - 인터럽트 발생");
        }
        log("작업 종료");
    }
}

• Thread.interrupted()는 현재 스레드의 인터럽트 상태를 확인한 후 초기화(false) 해준다.
• 따라서 인터럽트 상태가 계속 유지되지 않고 한 번만 감지되어 정상적으로 종료된다.

인터럽트 상태 관리의 중요성

1. interrupt()가 호출된다고 즉시 InterruptedException이 발생하는 것이 아니다.
2. sleep(), wait(), join() 같은 메서드를 호출해야만 InterruptedException이 발생한다.
3. 인터럽트 상태가 true라면, InterruptedException이 발생하면서 다시 false로 초기화된다.
4. isInterrupted()는 단순 확인만 하고 초기화하지 않는다.
5. Thread.interrupted()는 인터럽트 상태를 확인한 후 false로 초기화하여 연속적인 예외 발생을 방지한다.

결론

Java에서 스레드를 안전하게 중단하려면 interrupt()와 Thread.interrupted()를 적절히 활용해야 한다. 특히, 인터럽트 예외 발생 후 상태를 초기화하지 않으면 스레드가 계속 인터럽트 상태를 유지하여 예상치 못한 동작을 유발할 수 있다. 따라서 올바른 방식으로 인터럽트를 처리하여 리소스를 안전하게 정리하는 것이 중요하다.

이제 인터럽트를 제대로 이해하고, 올바르게 적용해 보자! 🚀

프로그래밍을 하다 보면 this라는 키워드를 자주 보게 됩니다. 특히 객체지향 언어(Java, JavaScript 등)에서 this는 매우 중요한 역할을 합니다. 그렇다면 this란 정확히 무엇일까요?

간단히 말해서, this는 호출된 인스턴스 메서드가 소속된 객체를 가리키는 참조 값입니다. 즉, 어떤 객체에서 메서드를 호출했는지 기억하는 역할을 합니다.

2. 스택 프레임과 this

어떤 스레드가 메서드를 호출하면, 스레드는 해당 메서드를 실행하기 위해 스택 프레임(Stack Frame) 을 생성합니다.

스택 프레임에는 메서드 실행과 관련된 정보가 저장되는데, 여기에는 this도 포함됩니다.

이해하기 쉽게 정리하면:

• 인스턴스의 메서드가 호출되면, 어떤 인스턴스에서 호출되었는지 기억해야 합니다.
• 이를 위해, 메서드가 실행될 때 해당 인스턴스의 참조값(this)을 스택 프레임에 저장합니다.
• 이후 메서드 내부에서 this를 사용하면, 스택 프레임에 저장된 this 값이 불러와집니다.

3. this가 중요한 이유

this가 있기 때문에 멀티 스레드 환경에서도 각 스레드는 자신이 실행 중인 객체를 구분할 수 있습니다.

예를 들어, 두 개의 스레드가 서로 다른 인스턴스를 사용한다고 가정해봅시다.

class Example {
    int value;

    void setValue(int value) {
        this.value = value; // this를 사용하여 현재 객체의 필드에 접근
    }
}

public class Main {
    public static void main(String[] args) {
        Example obj1 = new Example();
        Example obj2 = new Example();

        Thread thread1 = new Thread(() -> {
            obj1.setValue(10);
        });

        Thread thread2 = new Thread(() -> {
            obj2.setValue(20);
        });

        thread1.start();
        thread2.start();
    }
}

위 코드에서 this가 없다면, setValue 메서드가 어떤 인스턴스의 필드를 변경해야 하는지 알 수 없습니다. 하지만 this 덕분에 각 스레드는 자신이 실행 중인 객체의 필드에 접근할 수 있습니다.

4. this의 역할 요약

1. this는 현재 실행 중인 메서드가 속한 객체의 참조 값이다.
2. 메서드가 실행될 때, this는 스택 프레임 내부에 저장된다.
3. this 덕분에 스레드별로 각 인스턴스를 구별하여 사용할 수 있다.
4. this는 필드에 접근할 때 자동으로 사용되므로 생략해도 된다.

5. 결론

this는 객체 지향 프로그래밍에서 필수적인 개념으로, 인스턴스 메서드가 어느 객체에서 실행되고 있는지 추적하는 역할을 합니다. 또한 멀티스레드 환경에서도 객체를 올바르게 구별하는 데 중요한 역할을 합니다.

이제 this의 개념을 명확하게 이해하고, 코드에서 적극적으로 활용해보세요!

스레드의 상태 (Thread States)

자바에서 스레드는 다음과 같은 주요 상태를 가집니다.

1. New (새로운 상태)

• 스레드가 생성되었지만 아직 실행되지 않은 상태입니다.
• Thread 객체가 생성되었지만 start() 메서드가 호출되지 않은 경우.
• 예제:

  Thread thread = new Thread(runnable);

2. Runnable (실행 가능 상태)

• 스레드가 실행 준비가 완료된 상태입니다.
• start() 메서드가 호출되면 이 상태로 전이됩니다.
• CPU가 할당되면 실행됩니다.
• 예제:

  thread.start();

• 참고: Runnable 상태에 있다고 해서 반드시 실행되는 것은 아닙니다! CPU 스케줄링에 의해 실행 여부가 결정됩니다.

3. Blocked (차단 상태)

• 스레드가 동기화 락을 얻지 못해 기다리는 상태입니다.
• 예를 들어 synchronized 블록에 진입하려고 할 때 락을 얻지 못하면 Blocked 상태가 됩니다.

4. Waiting (대기 상태)

• 스레드가 무기한으로 다른 스레드의 작업을 기다리는 상태입니다.
• wait(), join() 등의 메서드를 호출하면 이 상태가 됩니다.
• 예제:

  synchronized(obj) {
      obj.wait(); // 무기한 대기 상태
  }

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

• 스레드가 일정 시간 동안 다른 스레드의 작업을 기다리는 상태입니다.
• sleep(long millis), wait(long timeout), join(long millis) 메서드 호출 시 해당 상태가 됩니다.
• 예제:

  Thread.sleep(1000); // 1초 동안 대기 (Timed Waiting)

6. Terminated (종료 상태)

• 스레드의 실행이 완료된 상태입니다.
• 정상 종료되거나 예외로 인해 종료될 수 있습니다.

스레드 상태 전이 과정

자바 스레드는 아래와 같은 상태 전이를 겪습니다.

1. New → Runnable

   • start() 호출 시 실행 가능 상태(Runnable)로 전이됨.

2. Runnable → Blocked / Waiting / Timed Waiting

   • Blocked: 스레드가 동기화 락을 얻지 못할 때.
   • Waiting: wait(), join() 등으로 무기한 대기할 때.
   • Timed Waiting: sleep(time), wait(time), join(time) 등으로 일정 시간 대기할 때.

3. Blocked / Waiting / Timed Waiting → Runnable

   • 락을 얻거나 대기 시간이 종료되면 다시 실행 가능 상태로 전이됨.

4. Runnable → Terminated

   • run() 메서드 실행이 끝나면 종료 상태(Terminated)가 됨.

마무리

자바 스레드는 New → Runnable → Running → Blocked/Waiting/Timed Waiting → Runnable → Terminated의 흐름을 따르며 실행됩니다. 운영체제의 스케줄러가 CPU 시간을 관리하므로, Runnable 상태에 있다고 즉시 실행되는 것이 아니라 스케줄러의 결정에 따라 실행된다는 점을 기억해야 합니다.

이해를 돕기 위해 아래 그림을 참고하면 좋습니다.

New → Runnable → Running → Terminated
                ↘
          Blocked / Waiting / Timed Waiting → Runnable

스레드의 상태를 적절히 관리하면 성능을 최적화하고, 동시성 문제를 방지할 수 있습니다. 스레드를 사용할 때 상태 전이를 잘 이해하고 활용하세요! ```

1. Thread 클래스를 상속하는 방식

✅ 장점

구현이 간단함 → Thread 클래스를 상속받고 run() 메서드만 오버라이딩하면 됨.

❌ 단점

상속의 제한 → Java는 단일 상속만을 지원하므로, 이미 다른 클래스를 상속받고 있다면 Thread를 상속받을 수 없음.

유연성이 부족함 → 실행할 작업을 스레드와 분리해서 관리하기 어려움.

📌 예제 코드

class MyThread extends Thread { public void run() { System.out.println("Thread 실행 중..."); } }

public class Main { public static void main(String[] args) { MyThread t = new MyThread(); t.start(); } }

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

✅ 장점

상속이 자유로움 → 이미 다른 클래스를 상속받고 있어도 Runnable을 구현할 수 있음.

코드의 분리 → 스레드와 실행할 작업을 분리하여 관리할 수 있어 유지보수가 쉬움.

자원 관리가 용이함 → 여러 스레드가 같은 Runnable 객체를 공유할 수 있어 자원을 효율적으로 관리할 수 있음.

❌ 단점

코드가 약간 복잡해짐 → Runnable 객체를 생성하고 이를 Thread에 전달하는 과정이 필요함.

📌 예제 코드

class MyRunnable implements Runnable { public void run() { System.out.println("Runnable 실행 중..."); } }

public class Main { public static void main(String[] args) { Thread t = new Thread(new MyRunnable()); t.start(); } }

3. 결론

✅ Runnable 인터페이스를 구현하는 방식을 사용하자!

Runnable 방식이 Thread 상속 방식보다 유연하고 유지보수하기 쉬운 코드 작성이 가능하다. 특히, 객체 지향적으로 코드를 관리하고 싶다면 Runnable을 적극적으로 활용하는 것이 좋다!

🚀 즉, Thread를 상속하는 방식은 단순하지만 제약이 많고, Runnable을 구현하는 방식이 더 확장성이 좋다!

Java에서 멀티스레드를 사용하려면 Thread 클래스를 상속받아 새로운 스레드를 생성할 수 있습니다. 이때 중요한 점은 start() 메서드를 호출하면 새로운 스레드가 실행되며, run() 메서드를 직접 호출하지 않는다는 점입니다.

이번 글에서는 Thread 클래스를 상속받아 실행하는 간단한 예제를 통해 start()와 run()의 차이점을 이해해보겠습니다.

💻 코드 예제

1️⃣ Thread 클래스 상속하여 스레드 생성

package thread.start;

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

Thread 클래스를 상속받아 HelloThread 클래스를 만듭니다. run() 메서드를 오버라이딩하여 실행할 코드를 작성합니다. Thread.currentThread().getName()을 사용해 현재 실행 중인 스레드의 이름을 출력합니다.

package thread.start;

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

        HelloThread helloThread = new HelloThread();  // 새로운 스레드 객체 생성
        System.out.println(Thread.currentThread().getName() + ": start() 호출 전");

        helloThread.start();  // 새로운 스레드를 시작

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

📌 실행 결과 예측 실제 실행 결과는 OS와 JVM 스케줄러에 따라 달라질 수 있지만, 일반적으로 아래와 같은 순서로 실행됩니다.

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

여기서 중요한 점을 살펴보겠습니다.

• main 스레드가 실행되면서 HelloThread 객체를 생성합니다.
• helloThread.start();를 호출하면 새로운 Thread-0 스레드가 시작됩니다.
• start()를 호출한 직후 main 스레드는 바로 다음 코드로 진행하며, run()이 실행될 때까지 기다리지 않습니다.
• Thread-0이 run() 메서드를 실행합니다.
• 스레드 간 실행 순서는 보장되지 않습니다. 따라서 main() 종료 전에 Thread-0이 실행될 수도 있고, 그 후에 실행될 수도 있습니다.

🚀 start() vs run() 차이점 메서드 동작 방식

• start() 새로운 스레드를 생성하고, run() 메서드를 실행하도록 함.
• run() 단순히 메서드를 실행할 뿐, 새로운 스레드를 생성하지 않음. helloThread.run(); // ❌ 새로운 스레드가 생성되지 않음 (일반 메서드 호출) helloThread.start(); // ✅ 새로운 스레드를 생성하여 실행

🔥 핵심 정리 ✅ main 스레드는 start()를 호출하여 새로운 스레드에게 실행을 지시할 뿐, 직접 run()을 실행하지 않는다. ✅ start()를 호출하면 새로운 스레드가 생성되고, run()이 실행된다. ✅ 스레드 실행 순서는 보장되지 않는다.

멀티스레드를 사용할 때는 스레드의 실행 흐름을 예측하기 어렵다는 점을 항상 염두에 두어야 합니다!

이 글에서는 메서드 영역, 스택 영역, 힙 영역의 개념과 차이점을 쉽게 설명하고,필요한 경우 자바 예제 코드도 함께 제공하겠습니다. 🚀

1. 메서드 영역 (Method Area)

📌 프로그램 실행에 필요한 공통 데이터를 저장하는 공간

✅ 주요 특징

• JVM이 프로그램 실행을 위해 클래스 정보를 저장하는 공간

• 모든 스레드(Thread)에서 공유됨

• 프로그램이 종료될 때까지 유지됨

✅ 저장되는 데이터

• 클래스 정보: 클래스 실행 코드(바이트코드), 필드 정보, 메서드 코드

• static 변수: 모든 인스턴스에서 공유하는 static 변수 저장

• 런타임 상수 풀: final static 값과 같은 상수 저장

✅ 메서드 영역 관련 자바 예제

public class MethodAreaExample { // static 변수 (메서드 영역에 저장됨) static int staticVar = 100;

// final static 변수 (런타임 상수 풀에 저장됨)
final static int CONSTANT = 200;

public static void main(String[] args) {
    System.out.println("Static Variable: " + staticVar);
    System.out.println("Constant Value: " + CONSTANT);
}

}

2. 스택 영역 (Stack Area)

📌 메서드 실행을 위한 메모리 공간 (LIFO 구조)

✅ 주요 특징

• 각 스레드(Thread)마다 개별적으로 할당됨

• 메서드가 호출되면 스택 프레임(Stack Frame)이 생성되고, 실행이 끝나면 제거됨

• GC(Garbage Collection)의 영향을 받지 않음 (자동 해제됨)

• LIFO(Last In, First Out) 구조

✅ 저장되는 데이터

• 지역 변수(Local Variables): 메서드 내에서 선언된 변수

• 매개변수(Parameters): 메서드 호출 시 전달된 인자 값

• 연산 중간 값: 연산을 수행하는 과정에서 저장되는 임시 값

• 리턴 값(Return Value): 메서드 실행이 끝난 후 반환되는 값

✅ 스택 영역 관련 자바 예제

public class StackExample { public static void main(String[] args) { int x = 10; // 지역 변수 (스택에 저장됨) int y = 20; // 지역 변수 (스택에 저장됨) int sum = add(x, y); // add() 메서드 호출 → 새로운 스택 프레임 생성 System.out.println("Sum: " + sum); }

public static int add(int a, int b) {
    int result = a + b;  // 새로운 스택 프레임에 변수 저장
    return result;  // 메서드 종료 시 스택 프레임 제거
}

}

3. 힙 영역 (Heap Area)

📌 객체와 배열이 저장되는 공간 (GC의 관리 대상)

✅ 주요 특징

• 객체(Object)와 배열(Array)이 저장됨

• GC(Garbage Collector)가 사용되지 않는 객체를 자동으로 회수

• 모든 스레드에서 공유됨

• JVM이 시작될 때 생성되며, 애플리케이션이 종료될 때까지 유지됨

✅ 저장되는 데이터

• 객체(Object): new 키워드로 생성된 객체

• 배열(Array): new 키워드로 생성된 배열

• 인스턴스 변수(Instance Variables): 객체 내부의 멤버 변수

✅ 힙 영역 관련 자바 예제

public class HeapExample { int instanceVar; // 인스턴스 변수 (힙 영역에 저장됨)

public HeapExample(int value) {
    this.instanceVar = value;
}

public static void main(String[] args) {
    HeapExample obj1 = new HeapExample(10); // 힙 영역에 객체 생성
    HeapExample obj2 = new HeapExample(20); // 힙 영역에 또 다른 객체 생성
    System.out.println("Object 1: " + obj1.instanceVar);
    System.out.println("Object 2: " + obj2.instanceVar);
}

}

4. 메모리 영역 비교 정리

5. 결론

자바의 메모리 구조를 이해하면 메모리 누수(Memory Leak) 방지, GC 최적화, 성능 개선 등에 도움이 됩니다.

💡 메모리 관리 최적화 방법

스택 오버플로우(StackOverflowError) 방지 → 재귀 호출 대신 반복문 사용

힙 메모리 부족(OutOfMemoryError) 방지 → 객체 참조 해제, 캐시 사용 고려

GC 최적화 → JVM 옵션(-Xms, -Xmx, -XX:+UseG1GC) 설정

이제 자바 프로그램에서 효율적인 메모리 관리를 할 수 있겠죠? 🚀