쏘니의 개발블로그

챗 gpt 책을 추천하려고 한다.

아래는 전체적인 내용을 요약한 개요다.

1부. 알아 두면 쓸모 있는 사전 지식

1장. 자연어 처리, 일상생활의 언어를 이해하여 분석하다
자연어 처리를 이해하기 위해 미리 알아 두자
__단어를 수치로 표현하다: 임베딩
__컴퓨터와 인간에게 맞는 표현으로 변환한다: 인코딩과 디코딩
__자연어 처리란?
자연어 처리를 효율적으로: 자연어 처리 알고리즘
__순환신경망(RNN)
__순환신경망 장단기 기억(LSTM)
__seq2seq와 어텐션
__트랜스포머, 버트, GPT
생성형 언어 모델, 챗GPT

2부. 챗GPT, 베일을 벗다

2장. 챗GPT가 궁금해?
챗GPT, 너의 정체가 궁금하다
__새로운 셀럽의 등장, 챗GPT
__챗GPT의 성과
__챗GPT의 동작 원리
챗GPT 플러그인
GPT-4의 등장
__GPT-4 모델
챗GPT의 형제들
__GPT-3 서비스
__달리(DALL-E) 서비스
__코덱스(Codex) 서비스
__위스퍼(Whisper) 서비스
GPT의 발전 과정

3장. 챗GPT의 등장으로 인한 변화
챗GPT의 등장과 구글의 종말
챗GPT에게 도전장을 내밀다
책임 있는 AI란?
챗GPT의 진실과 거짓
챗GPT의 한계

4장. 오픈AI와 마이크로소프트
오픈AI와 마이크로소프트의 관계
__마이크로소프트의 12조 원 투자
__오픈AI의 챗GPT와 마이크로소프트의 챗GPT
마이크로소프트 빙
마이크로소프트 코파일럿
마이크로소프트 루프

3부. 챗GPT 시작하기, 파인 튜닝과 API

5장. 챗GPT 만들기
챗GPT 시작하기
__챗GPT에 질문하기
__오픈AI에서 발급하는 API 키 획득하기
__애저에서 챗GPT를 사용하기 위한 준비
우리 기업만의 챗GPT를 위한 학습
__퓨샷, 원샷, 제로샷 러닝
__퓨샷, 원샷 러닝을 사용하기 위한 구성
파인 튜닝
챗GPT API는 어떻게 사용할까?
__GPT-3 API 사용하기
__GPT-3 파인 튜닝
__챗GPT API 사용하기
__위스퍼 사용하기
__애저에서 챗GPT 사용하기

4부. 글쓰기부터 코딩까지, 다양한 챗GPT 활용

6장. 챗GPT 활용하기
챗GPT를 사용하기 위한 유스케이스
업무에 챗GPT 활용하기
__물어볼 곳이 없다? 챗GPT에게 물어보자
__엑셀에서도 챗GPT를 사용할 수 있다고?
코딩, 참 쉽죠?
캐릭터도 인공지능으로 뚝딱!
고립인 듯 고립 아닌 삶
교사는 챗GPT가 싫다
__챗GPT로 과제하기
__챗GPT로 작성한 과제 찾아내기

전문지식을 함께 전달하기에 일반인이 읽기에 낯선 용어들이 등장하기도 하지만 깔끔한 편집과 그림을 활용한 설명이 많아 어려운 부분은 천천히 읽다 보면 이해를 할 수 있었고 깊이 있는 지식을 익힐 수 있어 좋다.

특히, 4부의 활용부분에서는 엑셀, 코딩 등 직접 활용할 수 있는 실제 활용법을 따라 해볼 수 있도록 자료를 통해 설명하고 있어 큰 도움이 된다.

총 4부로 구성된 이 책은 알아 두면 쓸모 있는 사전 지식, 챗GPT 베일을 벗다, 챗GPT 시작하기, 파인 튜닝과 API, 글쓰기부터 코딩까지 다양한 챗GPT 활용으로 나뉘어 세세하고 깊이 있는 정보를 알차게 전달하고 있다.

자연어 처리를 이해하기 위한 몇 가지 개념을 익히고 자연어 처리와 챗GPT에 대한 설명, 챗GPT의 개념과 동작 원리를 이해하고 GPT-4에 대한 정보, GPT-3, 달리, 코덱스, 위스퍼, GPT의 발전 과정, 챗GPT 등장으로 인한 변화와 챗GPT를 둘러싼 소문의 진위여부, 한계점, 오픈 AI와 마이크로소프트, 챗GPT의 활용, 챗GPT를 만들기 위한 챗GPT API와 파인 튜닝 등 챗GPT와 관련된 모든 정보를 한 권으로 차근히 배울 수 있다.​

결론을 말하자면 책을 실습만을 위한 책은 아니고, 처음 입문하기에는 좋은 책으로 보인다. 

이 책을 입문으로 조금 더 학습하는게 나을 것 같다.

1. 왜 이 책을 선택하였나?

현업 7년차 개발자로 스프링 및 개발에 처음 입문하는 누군가에게 추천해줄 책을 찾고 있었다.

그러던 중 이 책이 예제를 통해 간단하게 스프링 입문하기 좋다는 느낌을 받았다. 일단 예제소스의 복잡도가 깊지 않고 간결해서 좋다. 

또한 1,2 장을 통하여 스프링에 처음 입문하는 사람들이 세팅할 수 있게 정리가 되어 있다.

그 이후의 장들은 간단하게 쇼핑몰을 구축해가면서 한단계씩 순차적으로 스프링에서 제공하는 많은 기능을 자유롭게 확장해 사용할 수 있으며 영역별로 개발할 수 있다는 장점이 있다.

또한, MultipartFile, RESTful 웹 서비스, 스프링 웹 플로우, 스프링 시큐리티, Log4j 등을 사용하기 때문에 다양한 스프링 기능도 함께 익힐 수 있다. 책을 따라 실습하다 보면 스프링 MVC의 개념과 원리를 자연스레 익힐 수 있을 것이다. 스프링 MVC가 처음이거나 스프링 MVC로 직접 웹 애플리케이션을 만들어 보고 싶은 분에게 추천한다.

2. 소개

1 - 스프링 과 스프링 MVC 개요

2 - 스프링 개발 환경 설정

3 - 프로젝트 만들기 기본구성

4 - 공통 구조 만들기

5 - 목록 조회 하기 만들기

6 - 다양한 내용의 요청 처리 방식

7 - 데이터 등록 구현

8 - 스프링 시큐리티, 로그인, 로그아웃 처리

9 - 파일 업로드

10 - 예외처리

11 - 로그 방식

12 - 다국어 처리

13- 유효성 검사

14 - RESTful 웹 서비스 개요

15 - 데이터베이스 연동

3. 아쉬운점 

요즘같이 마이크로서비스가 주목받는 시기에 스프링 기본서를 처음부터 끝까지 다 리딩할 수 있는 분이 있을까 싶긴하다. 

스프링 부트 및 rest api 로만 업무를 처리할 사람에게는 굳이 필요없는 jsp 등의 화면 코드도 작성해야 한다.

코드 : https://github.com/gilbutITbook/080266

도커를 실무에서 사용하고 있어서 책을 통해서 더 배울게 있나 했는데, 도커교과서 라는 교재를 보니 아직 알아야 할게 너무 많은 걸 알았다.

요즘 도커를 안쓰고 개발을 하기가 어렵다. 실무에서 쓰지 않는다고 하더라도 도커는 알아야 외부 개발자와의 간단한 미팅에서라도 무시당하지 않는다. 개발자 친구가 도커를 전혀 모른다고 하면 내심 무시당할 수 있다. 자세히는 모르더라도 도커가 뭔지는 알아야 한다. 또한 요즘 쿠버네티스 또한 안하는 회사를 점차 찾기 힘들어졌다. 이런 쿠버네티스를 도입하려면 도커는 정말 필수적으로 알아야 하는 기본 지식이 되어버렸다.

이 책을 보면 도커를 처음 시작하는 사람부터 실습가능하게 설명이 되어 있다. 

도커의 기본적인 사용법부터 Dockerfile 로 도커이미지 생성하는 내용을 통해 기본적인 도커 방식 및 개념을 이해 할 수 있다. 

예제로 자바 및 node.js, go 코드에 대한 샘플도 있다. 

기본적인 내용을 학습하고 나면 도커 이미지를 저장할 레지스트리 및 도커 볼륨 등 옵션적인 내용도 학습할 수 있다. 물론 도커를 한다면 도커컴포즈 내용도 알아야 하기 때문에 해당 내용도 교재에 잘 정리되어 있다. 

그 이후의 내용은 도커를 사용한다고 해도 잘 모를 수 도 있는 내용들이었고, 이에 대해 학습할 수 있어서 이 교재를 더 추천하는 이유다.

컨테이너화된 애플리케이션에 사용되는 모니터링 기술 스택 및 도커 스웜을 통한 분산 애플리케이션 배포 등등 쿠버네티스를 학습하기 전 이 책을 통해 도커에 대해 정확히 알고 넘어가야 할 것 같다.

이 책을 필요로 할 사람으로는 도커를 실무에 적용하고 싶은 분 및 실무에 도커를 적용하나 간단하게 적용 하거나 잘 모르는 부분이 있어 정확히 알고자 하는 분 이 좋을 것 같다. 혹시나 이제 개발을 입문하는 학생 및 교육과정을 수료하는 취준생들에게는 맞지 않을 것 같다.

여태 도커에 대해 잘 몰랐던 거 같아 자책이 들지만, 이 책을 하루빨리 정독해서 바로 다음 스텝 쿠버네티스로 넘어가야 겠다.

구매정보

http://www.yes24.com/Product/Goods/111408749

private 생성자나 열거 타입으로 싱글턴임을 보증하라

싱글톤을 만드는 방법고 어떻게 만드는 것이 효율적일지 볼 수 있다.

싱글톤이란

인스턴스를 오직 하나만 생성할 수 있는 클래스이다.

싱글턴을 만드는 방식

생성자는 private 으로 감춰두고, 인스턴스에 접근할 수 있는 수단으로 public static 멤버를 만든다.

방법 1. public static 멤버가 FInal 필드인 방식

public class Single {
	public static final Single INTANCE = new Single();
    private Single() { ... }
    
    public void 메소드동작() {
     ...
    }
}

설명 : private 생성자는 PUBLIC Static final 필드인 Single.INSTANCE 를 초기화할 때 한번만 호출된다.

public 이나 Protected 생성자가 없으므로 Single 클래스가 초기화될때 만들어진 인스턴스가 전체 시스템에서 하나뿐인게 보장된다.

혹여나 리플랙션 API 로 private 생성자를 호출할 수 있지만, 이러한 것도 방어하려면 생성자를 수정하여 두번째 객체가 생성되려 할때 예외를 던지게 하면 된다.

장점 :

1) 해당 클래스가 싱글턴임을 API 를 보고 바로 알 수 있다.

public static 필드가 final 이라 절대로 다른 객체를 참조 할 수 없다.

2) 간결함

2. 정적 팩터리 메서드를 public static 멤버로 제공하자.

public class Single {
	private static final Single INTANCE = new Single();
    private Single() { ... }
    
    public static Single getIntance() { return INTANCE; }
    
    public void 메소드() {
    	...
    }
}

설명 : Single.getIntance 는 항상 같은 객체의 참조를 반환하므로 하나의 객체만 생성된다.

장점 :

1) 개발자의 의도가 바뀌면 API를 바꾸지 않고도 싱글톤이 아니게 변경 가능하다.

팩토리 메소드가 호출하는 스레드별로 다른 인스턴스를 넘겨주게 할 수 있다.

2) 또한 원한다면 정적 팩터리를 제네릭 싱글턴 팩터리로 만들수 있다.

3) 정적 팩터리의 메소드 참조를 공급자(supplier) 로 사용할 수 있다. 

Single::getIntance 를 Supplier<Single> 로 사용하는 방법이다.

위의 장점들이 필요하지 않다면 방법1 public 필드 방식이 좋다.

둘 중 하나의 방식으로 만든 싱글턴 클래스를 직렬화하려면 Serializable 을 구현한다고 선언하는 것만으로 부족하다.

모든 인스턴스 필드를 transient 라고 선언하고 readResolbe 메소드를 제공해야 한다.

이렇게 하지 않으면 직렬화된 인스턴스를 역직렬화할 때마다 새로운 인스턴스가 만들어진다.

// 싱글톤임을 보장해주는 READREsolve 메소드
private Object readResolve() {
	// '진짜' Single 를 반환하고 '가짜' 객체 Single 는 가비지 컬렉터에 맡긴다.
    return INSTANCE;
}

3. 원소가 하나인 열거 타입을 선언하자

public enum Single {
	INSTANCE;
    
    public void 메소드() {
    	...
    }
}

설명 :

1) 방법 1 Public 필드 방식과 비슷하지만 더 간결하고 추가 노력 없이 직렬화 할 수 있다.

2) 또한 복잡한 직렬화 상황이나 리플렉션에서도 인스턴스가 추가되는 것을 막아준다.

대부분의 상황에서는 원소가 하나뿐인 ENUM 타입이 싱글턴을 만드는 가장 좋은 방법이다.

대신 싱글톤이 Enum 외의 클래스를 상속해야 하면 이 방법은 사용불가 (열거 타입이 다른 인터페이스를 구현하도록 선언할 수는 있다.) 

-> 책에서의 이 말이 이해가 안감........

점층적 생성자 패턴도 쓸 수는 있지만, 매개변수 개수가 많아지면 클라이언트 코드를 작성하거나 읽기 어렵다.

setter 를 통해서 객체값 세팅(자바빈즈 패턴) 에서는 객체 하나를 만들기 위해 메서드를 여러 개 호출해야 하고, 객체가 완전히 생성되기 전까지는 일관성이 무너지게 된다.

자바빈즈 패턴에서는 클래스를 불변으로 만들 수 없다.

이러한 객체 불변과 점층적 생성자 패턴의 대안은 빌더 패턴이다.

빌더는 생성할 클래스 안에 정적 멤버 클래스로 만들어두는게 보통이다.

// 코드 2-3 빌더 패턴 - 점층적 생성자 패턴과 자바빈즈 패턴의 장점만 취했다. (17~18쪽)
public class NutritionFacts {
    private final int servingSize;
    private final int servings;
    private final int calories;
    private final int fat;
    private final int sodium;
    private final int carbohydrate;

    public static class Builder {
        // 필수 매개변수
        private final int servingSize;
        private final int servings;

        // 선택 매개변수 - 기본값으로 초기화한다.
        private int calories      = 0;
        private int fat           = 0;
        private int sodium        = 0;
        private int carbohydrate  = 0;

        public Builder(int servingSize, int servings) {
            this.servingSize = servingSize;
            this.servings    = servings;
        }

        public Builder calories(int val)
        { calories = val;      return this; }
        public Builder fat(int val)
        { fat = val;           return this; }
        public Builder sodium(int val)
        { sodium = val;        return this; }
        public Builder carbohydrate(int val)
        { carbohydrate = val;  return this; }

        public NutritionFacts build() {
            return new NutritionFacts(this);
        }
    }

    private NutritionFacts(Builder builder) {
        servingSize  = builder.servingSize;
        servings     = builder.servings;
        calories     = builder.calories;
        fat          = builder.fat;
        sodium       = builder.sodium;
        carbohydrate = builder.carbohydrate;
    }

    public static void main(String[] args) {
        NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)
                .calories(100).sodium(35).carbohydrate(27).build();
    }
}

빌더의 세터 메서드들은 빌더 자신을 반환하기 때문에 연쇄적으로 호출 할 수 있다. 이런 방식을 플루언트 API 혹은 메서드 연쇄(method chaning) 라고 한다.

빌더 패턴은 계층적으로 설계된 클래스와 함께 쓰기에 좋다.

추상 클래스는 추상빌더를 구체 클래스는 구체 빌더를 갖게 한다,

// 코드 2-4 계층적으로 설계된 클래스와 잘 어울리는 빌더 패턴 (19쪽)

// 참고: 여기서 사용한 '시뮬레이트한 셀프 타입(simulated self-type)' 관용구는
// 빌더뿐 아니라 임의의 유동적인 계층구조를 허용한다.

public abstract class Pizza {
    public enum Topping { HAM, MUSHROOM, ONION, PEPPER, SAUSAGE }
    final Set<Topping> toppings;

    abstract static class Builder<T extends Builder<T>> {
        EnumSet<Topping> toppings = EnumSet.noneOf(Topping.class);
        public T addTopping(Topping topping) {
            toppings.add(Objects.requireNonNull(topping));
            return self();
        }

        abstract Pizza build();

        // 하위 클래스는 이 메서드를 재정의(overriding)하여
        // "this"를 반환하도록 해야 한다.
        protected abstract T self();
    }
    
    Pizza(Builder<?> builder) {
        toppings = builder.toppings.clone(); // 아이템 50 참조
    }
}

추상메서드인 self 를 더해 하위 클래스에서는 형변환하지 않고드 메서드 연쇄를 지원할 수 있다.

// 코드 2-5 뉴욕 피자 - 계층적 빌더를 활용한 하위 클래스 (20쪽)
public class NyPizza extends Pizza {
    public enum Size { SMALL, MEDIUM, LARGE }
    private final Size size;

    public static class Builder extends Pizza.Builder<Builder> {
        private final Size size;

        public Builder(Size size) {
            this.size = Objects.requireNonNull(size);
        }

        @Override public NyPizza build() {
            return new NyPizza(this);
        }

        @Override protected Builder self() { return this; }
    }

    private NyPizza(Builder builder) {
        super(builder);
        size = builder.size;
    }

    @Override public String toString() {
        return toppings + "로 토핑한 뉴욕 피자";
    }
}

// 코드 2-6 칼초네 피자 - 계층적 빌더를 활용한 하위 클래스 (20~21쪽)
public class Calzone extends Pizza {
    private final boolean sauceInside;

    public static class Builder extends Pizza.Builder<Builder> {
        private boolean sauceInside = false; // 기본값

        public Builder sauceInside() {
            sauceInside = true;
            return this;
        }

        @Override public Calzone build() {
            return new Calzone(this);
        }

        @Override protected Builder self() { return this; }
    }

    private Calzone(Builder builder) {
        super(builder);
        sauceInside = builder.sauceInside;
    }

    @Override public String toString() {
        return String.format("%s로 토핑한 칼초네 피자 (소스는 %s에)",
                toppings, sauceInside ? "안" : "바깥");
    }
}

각각의 Calzone 과 NyPizza Builder 는 NyPizza 와 Calzone 를 반환한다. 하위 클래스의 메서드가 상위 클래스의 메서드가 정의한 반환 타입이 아닌 그 하위 타입을 반환하는 기능을 공변 반환 타이핑(covariant return typing) 이라 한다.

이 기능을 이용하면 클라이언트가 형변환에 신경 쓰지 않고도 빌더를 사용할 수 있다.

2장. 객체 생성과 파괴

아이템 1. 생성자 대신 정적 팩터리 메서드를 고려해라.

정적팩터리 메서드가 생성자보다 좋은 장점 다섯가지

1. 이름을 가질수 있다.

생성자에 넘기는 매개변수와 생성자 자체로는 반환되는 객체의 특성을 알 수 가 없다. 

BigInteger (int, int, Random) vs BigInteger.probablePrime 중에 값이 소수인 BigInteger 를 반환하는 것을 알기 쉽다.

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

Boolean.valueOf(boolean) 메서드는 객체를 생성하지 않는다. 

반복되는 요청에 같은 객체를 반환하는 식으로 언제 어느 인스턴스를 살아 있게 할지를 철저히 통제 가능. instance-controlled (인스턴스 통제)

3. 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.

API를 만들 때 이 유연성을 응용하면 구현 클래스를 공개하지 않아도 그 객체를 반환할 수 있어 API를 작게 유지할 수 있다.

자바 8 부터 인터페이스를 정적 메소드로 선언 가능하다.

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

반환 타입의 하위 타입이기만 하면어떤 클래스의 객체를 반환하든 상관 없다.

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

이런 점은 서비스 제공자 프레임워크(service provider framework)를 만드는 토대가 된다. 대표적인 예시로는 JDBC. 

서비스 제공자 프레임워크는 3개의 핵심 컴포넌트로 구성.

- 구현체의 동작을 정의하는 서비스 인터페이스

- 제공자가 구현체를 등록 할 때 사용하는 제공자 등록 API

- 클라이언트가 서비스의 인스턴스를 얻을 떄 사용하는 접근 API

여기서 서비스 접근 API 가 유연한 정적 팩터리 이다.

서비스 제공자 API 인터페이스가 없다면 각 구현체를 인스턴스로 만들 떄 리플렉션을 사용해야 한다.

JDBC 에서는 Connectin 이 서비스 인터페이스 역할을, DriverManager.registerDriver 가 제공자 등록 API 역할.

DriverManager.getConnection 이 서비스 접근 API 역할을, Driver 가 서비스 제공자 인터페이스 역할을 수행한다.

여기서 서비스 접근 API 는 공급자가 제공하는 것보다 더 풍부한 서비스 인터페이스를 클라이언트에 반환할 수 있다.

단점

1. 상속을 하려면 public 이나 protected 생성자가 필요하니 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다.

2. 정적 팩터리 메서드는 프로그래머가 찾기 어렵다. 네이밍으로 해결

• from: 매개변수를 받아 해당 타입의 인스턴스를 반환하는 형변환 메서드 
  ex) Date d = Date.from(instant)
• of: 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메서드 
  ex) Set<Rank> faceCards = EnumSet.of(JACK, QUEEN, KING)
• valueOf : from 과 of 의 더 자세한 버전 -                                                                                                                                   ex) BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE)
• instance 혹은 getInstance : 매개변수로 명시한 인스턴스를 반환하지만, 같은 인스턴스임을 보장 하지 않는다.                              ex) StackerWaker luke = StackWalker.gtInstance(options)
• create 혹은 newInstance : 매번 새로운 인스턴스를 생성해 반환                                                                                                  ex) Object newArray = Array.newInstance(classObject, arrayLen)
• getType : 생성할 클래스가아닌 다른 클래스에 정의할 때 사용.
  ex) FileStore fs = Files.getFileStore(path)
• newType : 생성할 클래스가 아닌 다른 클래스에 정의할 때 사용 
  ex) BufferedReader br = Files.newBufferedReader(path)
• type: getType 과 newType 의 축약 
  ex) List<Company> litnay = Collection.list(legacyLitany)

정리

정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하자.

그래도 정적팩터리를 사용하는게 유리한 경우가 더 많으므로, 무조건 생성자를 제공하는 습관은 버리자.

이펙티브 자바 3판입니다.

이 책은 자바 중급 이상의 책이고, 자바 개발자들이 한번쯤 읽어봐야 할 책으로 중급개발자로 나아가기 위한 책이라고 많이 들어서 정주행 하려고 합니다.

자바 8에 대한 이해도를 높이기 위해서도 이 책을 추천할 만한 책인 것 같습니다.

책의 예제 코드입니다.

https://github.com/WegraLee/effective-java-3e-source-code

책 서평에 적혀 있는 공식 강의입니다.

백기선님의 유튜브 강의입니다. 정말 대단하신 분이네요. 인프런 강의도 엄청 많은데,,,,,

https://www.youtube.com/watch?v=X7RXP6EI-5E&list=PLfI752FpVCS8e5ACdi5dpwLdlVkn0QgJJ

CompletableFuture와 리액티브 프로그래밍 컨셉의 기초

• Thread, Future, 자바가 풍부한 동시성 API를 제공하도록 강요하는 진화의 힘
• 비동기 API
• 동시 컴퓨팅의 박스와 채널 뷰
• CompletableFuture 콤비네이터로 박스를 동적으로 연결
• 리액티브 프로그래밍용 자바 9플로 API의 기초를 이루는 발행 구독 프로토콜
• 리액티브 프로그래밍과 리액티브 시스템

15.1 동시성을 구현하는 자바 지원의 진화

멀티코어 CPI에서 효과적으로 프로그래밍을 실행할 필요성이 커지면서 이후 자바 버젼에서는 개선된 동시성 지원이 추가됨.

자바는 Future를 조합하는 기능을 추가하면서 동시성을 강화

15.1.2 Executor와 스레드 풀

자바5는 Executor 프레임워크와 스레드 풀을 통해 스레드의 힘을 높은 수준으로 끌어올리는 즉 자바 프로그래머가 태스크 제출과 실행을 분리할 수 있는 기능 제공.

스레드의 문제

자바 스레드는 직접 운영체제 스레드에 접근한다. 운영체제가 지원하는 스레드 수를 초과해 사용하면 자바 애플리케이션이 예상치 못한 방식으로 크래시될 수 있으므르 기존스레드가 실행되는 상태에서 계속 새로운 스레드를 만드는 상황이 일어나지 않도록 주의해야 한다.

스레드 풀 그리고 스레드 풀이 더 좋은이유

자바 ExecutorService 는 태스크를 제출하고 나중에 결과를 수집할 수 있는 인터페이스를 제공한다.

워커스레드라 불리는 nThreads를 포함하는 ExecutorService 를 만들고 이들을 스레드 풀에 저장한다. 스레드 풀에서 사용하지 않은 스레드로 제출된 태스크를 먼저 온 순서대로 실행한다. 태스크 실행이 종료되면 이들 스레드를 풀로 반환한다.

장점은 하드웨어에 맞는 수의 태스크를 유지함과 동시에 수 천개의 태스크를 스레드 풀에 아무 오버헤드 없이 제출할 수 있다.

태스크(Runnable 이나 Callable) 를 제공하면 스레드가 이를 실행

스레드 풀 그리고 스레드 풀이 나쁜 이유

잠을 자거나 I/O를 기다리거나 네트워크 연결을 기다리는 태스크가 있다면 주의.

블록(자거나 이벤트를 기다리는)할 수 있는 태스크는 스레드 풀에 제출하지 말아야 한다.

15.1.3 스레드의 다른 추상화 : 중첩되지 않은 메서드 호출

• 스레드 실행은 메서드를 호출한 다음의 코드와 동시에 실행되므로 데이터 경쟁 문제를 일으키지 않도록 주의해야한다.
• 기존 실행 중이던 스레드가 종료되지 않은 상황에서 자바의 main() 메서드가 반환하면 

    - 애플리케이션을 종료하지 못하고 모든 스레드가 실행을 끝낼 때까지 기다린다.

    - 애플리케이션 종료를 방해하는 스레드를 강제종료 시키고 애플리케이션을 종료한다.

15.2 동기 API와 비동기 API

자바 5의 Future는 자바 8의 CompletableFuture로 이들을 조합하여 비동기 구현 가능

15.2.3 잠자기 는 해로운것으로 간주

10초 동안 워커 스레드를 점유한 상태에서 아무것도 안하는 코드

work1();
Thread.sleep(1000);
work2();

다른 작업이 실행될 수 있도록 허용하는 코드(스레드를 사용할 필요가 없이 메모리만 조금 더 사용)

work1();
scheduledExecutorService.schedule(ScheduledExecutorServiceExample::work2, 10, TimeUnit.SECONDS);

태스크가 실행되면 귀중한 자원을 점유하므로 태스크가 끝나서 자원을 해제하기 전까지 태스크를 계속 실행해야 한다.

태스크를 블록하는 것보다는 다음 작업을 태스크로 제출하고 현재 태스크는 종료하는 것이 바람직.