Fork(나누고)/Join(모으고)

Fork는 여러 개를 나누는 작업을 말하고, Join은 작업 결과를 모으는 것이라고 생각하면 된다.

여기서 나아가 Work Stealing이라는 개념도 들어가는데,

Work Stealing

여러 개의 Dequeue에 작업이 나뉘어져 어떤 일이 진행될 때 만약 하나의 Dequeue는 바쁘고, 다른 Dequeue는 바쁘지 않을 때가 있다. 이럴 경우 할 일이 없는 Dequeue가 바쁜 Dequeue에 대기하고 있는 일을 가져가서 해 주는 것이라고 생각하면 된다. (※참고 : 입구와 출구가 정해져 있는 Queue와는 달리, Dequeue는 양쪽 끝이 모두 입구와 출구가 되는 구조이다.)

이같은 Work Stealing이 Fork/Join에 기본적으로 포함돼 있다.

기본적인 수행 개념은 다음과 같다.

if(작업 단위가 충분히 작을 경우){
    해당작업 수행
}else{
    작업을 반으로 쪼개어 두 개 작업으로 나눔.
    두 작업을 동시에 실행, 두 작업 끝날 때까지 결과를 기다림
}

보통 이 연산은 회귀적(Recursive)으로 수행된다.

Fork/Join을 사용하는 클래스

ForkJoinPool을 사용하려면 기본적으로 알아야 할 클래스들이 있다.

• ForkJoinPool

  • fork-join방식으로 타스크를 생성하고 동작시키는 ForkJoin Framework의 모체

• RecursiveTask

  • 실제 작업의 단위가 되는 클래스는 이 클래스를 상속해야 한다. 또한 compute메소드에서 결과값을 리턴해야 한다.

• RecursiveAction

  • RecursiveTask과 같은 용도로서, 작업의 단위가 되는 클래스가 상속해야 하는 클래스이다. 결과는 리턴하지 않는다.

• ForkJoinTask

  • RecursiveTask의 부모클래스스로서 fork와 join메소드가 정의되어있다. 직접적으로 사용하지는 않는다.

java7에서 변경된 것들

숫자 표시 방법 보완

• 이전 버전까지는 0을 앞에 넣으면 8진수, 0x를 앞에 넣으면 16진수로 인식하는 것이 가능했다. java7부터는 아무 접두사가 없는 숫자는 10진수, 0b를 앞에 넣으면 2진수로 인식하는 것이 추가됐다.
• _를 사용하여 숫자의 단위를 잘라서 표현할 수 있다. 가독성이 좋아졌다.

  switch문에서 String 사용

• java6까지는 switch-case에서 정수형만 사용가능했었다. 7부터 String도 사용이 가능하다.

제네릭을 쉽게 사용할 수 있는 Diamond

• 기존에는 제네릭 사용 시에 <>안에 타입을 입력했어야 했다. 7부터는 그럴 필요가 없다. 왜냐하면 이미 변수 선언부에서 타입을 지정해놨기 때문이다.

예외가 보완되었다.(1)

이전까지는 예외처리르 ㄹ위해 try-catch문장을 사용했다. 이 부분에서 catch로 잡아주는 코드의 가독성이 떨어졌다.

    public void scanFile(String fileName, String encoding){
        Scanner scanner = null;
        try{
            scanner = new Scanner(new File(fileName), encoding);
            System.out.println(scanner.nextLine());
        }catch(IllegalAccessException iae){
            iae.printStackTrace();
        }catch(FileNotFoundException ffe){
            ffe.printStackTrace();
        }catch(NullPointerException npe){
            npe.printStackTrace();
        }catch(Exception e){
            e.printStackTrace();
        }finally{
            if(scanner != null){
            scanner.close();
            }
        }
    }

위의 예시를 보면 파일명이 한글일 경우 타입명시를 해줘야 한다. 인코딩 타입이 존재하지 않을 경우에, IllegalArgumentException이 발생할 것이고, 파일이 존재하지 않을 경우에는 FileNotFoundException이 발생할 것이다. 파일명이나 인코딩 타입이 NullPointerException이 발생할 수 있다. 지금까지는 일일이 발생할 만한 case에 맞춰서 catch블록을 만들어 처리하고, 마지막에 Exception 클래스로 catch해주는 것이 일반적이었다.

그러나 이제 java7부터는 다음과 같이 처리할 수 있다.

    public void newScanFile(String fileName, String encoding){
        Scanner scanner = null;
        try{
            scanner = new Scanner(new File(fileName), encoding);
            System.out.println(scanner.nextLine());
        }catch(IllegalArgumentException | FileNotFoundException | NullPointerException exception){
            exception.printStackTrace();
        }finally{
            if(scanner != null){
            scanner.close();
            }
        }    
    }

예외가 보완되었다.(2)

try-with-resource(리소스와 함께 처리하는 try문장)이다. 아래 예시를 보자.

  public void newScanFileTryWithResource(String fileName, String encoding){
      try(Scanner scanner = new Scanner(new File(fileName), encoding)){
          System.out.println(scanner.nextLine());
      }catch(IllegalArgumentException | FileNotFoundException | NullPointerException exception){
      exception.printStackTrace();
      }    
  }

이 구문의 특징은 다음과 같다.

• try의 소괄호 내에서 예외가 발생할 수 있는 객체에서, close()를 이용해 닫아야할 필요가 있을 때, AutoCloseable을 구현한 객체는 finally문장에서 별도로 처리할 필요가 없다는 것을 볼 수 있다. (AutoCloseable에 대해서는 아래에서 이어 말하겠다. )

AutoCloseable

java5부터 추가된 java.io.Closeable인터페이스를 구현한 클래스들은 명시적으로 close()메소드를 사용하여 닫아줘야했지만, java7에 추가된 AutoCloseable 인터페이스를 상속한 클래스들은 앞서 살펴본 try-with-resource구문을 사용할 수 있다. AutoCloseable을 상속한 클래스들은 아래와 같다. (이외에도 많다.)

• java.nio.channels.FileLock
• java.beans.XMLEncoder
• java.beans.XMLDecoder
• java.io.ObjectInput
• java.io.ObjectOutput
• java.util.Scanner
• java.sql.Connection
• java.sql.ResultSet
• java.sql.Statement

출처 : 자바의 신(이상민 저)

Optional

• null인 객체를 처리하기 위한 클래스

default 메소드

• 원래 interface를 구현하는 클래스에서는 interface에 있는 메소드를 모두 구현하여야 컴파일 오류가 발생하지 않는다.
• 이와는 다르게 default를 사용하여 interface에 선언한 메소드는 필수가 아닌 선택적으로 구현여부를 정할 수 있다.
• 이렇게 만든 이유는 과거에 만든 소스가 많은 개발자들에게 사용되는 상황에서 기존의 interface에 새로운 메소드를 추가해야하는 상황이 발생했기 때문이다. 기능 추가는 가능하되 컴파일 에러를 피할 수 있다.

Lambda

• 익명클래스 대용으로 사용하기 위해 만들어짐. => 익명클래스는 뭔가? 클래스 상속이나 인터페이스 구현을 위한 클래스를 생성하지 않고도 , 단일 객체를 만들어서 상속하려는 클래스나 구현하려는 인터페이스에 정의된 동작에 행위를 추가할 수 있게 하는 클래스이다.
• lambda는 메소드가 하나만 선언된 인터페이스에 대해서만 사용할 수 있다.
• 2개 이상 선언되면 컴파일 오류가 발생하는데, 이것을 방지하기 위해 @FunctionalInterface라는 어노테이션을 제공한다.

java.util.function 패키지

• predicate, Supplier, Consumer, Function, UnaryOperator, BinaryOperator

Stream

• 연속된 정보를 처리하는 데 사용한다.
• 기존에는 배열이나 컬렉션을 통해 연속된 정보를 사용해 왔다.

스트림은 아래와 같은 기본구조를 가진다.

list.stream().filter(x-> x>10).count()

• .stream() : 스트림을 생성한다.
• .fileter() : 중개연산을 한다. 리턴값이 없다.
• .count() : 종단 연산을 한다. 중개연산 작업 후에 마지막 종단연산 하고 리턴한다.

스트림에서 제공하는 연산의 종류는 많다. 그중에서 많이 사용하는 것들은 .filter(), map(), forEach()정도가 있겠다.

stream forEach()는 주어진 객체에서 루프를 돌면서 명령을 수행한다.

stream.map()

• map()메소드는 객체를 데이터로 바꾸는 것(x)
• 스트림의 값을 변환한다.

stream.filter()

• 말 그대로 조건에 맞는 데이터를 걸러내는 것이라고 생각하면 된다.

메소드 참조(Method Reference)

더블콜론을 사용한다.

• static 메소드 참조( 클래스 내에 선언된 static 메소드를 참조할 수 있다. 클래스명::메소드명)
• 특정 객체의 인스턴스 메소드 참조 ( System 클래스의 out에 저장된 printStream의 객체를 참조하여 println()을 호출한다.)
• 특정 유형의 임의의 객체에 대한 인스턴스 메소드 참조(
• 생성자 참조

경험있고 능력있는 개발자라면 코드를 짤 때 어플리케이션의 성능과 안정성 등을 고려할 것이지만, 부끄럽게도 나는 어플리케이션의 성능과 안정성보다는 로직의 구현 자체에 신경을 쓰는 수준이라는 생각이 드는 경향이 있다고 느껴지는 편이라고 여겨진다...ㅠㅠ(인정하고 싶어하지 않는 몸부림ㅠㅠㅠㅠ)

코드를 실행하고 내 눈앞에 결과가 나타나기까지의 과정의 중심에는 JVM이 있다. JVM을 빼놓고는 JAVA를 말할 수 없으니 꼭 이 기회에 짚고 넘어가 보자..!!

JVM은 무슨 일을 하나?

• 실행될 클래스 파일을 메모리에 로드 후 초기화 작업 수행

• 메소드와 클래스변수들을 해당 메모리 영역애 배치
• 클래스로드가 끝난 후 JVM은 main 메소드를 찾아 지역변수, 객체변수, 참조변수를 스택에 쌓음
• 다음 라인을 진행하면서 상황에 맞는 작업 수행(함수 호출, 객체 할당 등)

JVM은 운영체제로부터 독립적이다.

어떻게?

일단 우리가 운영체제에서 Java를 사용하려면 JDK를 설치해야 한다. 여기서 이 JDK는 운영체제별 종류가 다르다. JDK안에는 JRE, API, JVM이 포함되어 있다. 즉, 운영체제마다 다른 JVM이 제공되기 때문에 독립적일 수 있다. (굳이 말하자면 JDK에 종속적이라고 할 수 있겠다.)

JVM 실행 절차

*JVM은 byteCode 파일을 기계어 코드로 변환하여 실행하는 역할을 한다. *

1. Java로 작성한 코드(.java)가 컴파일
2. 바이트코드(.class)파일로 만들어짐
3. 이 파일은 JVM을 거쳐서 기계어 코드파일로 변환된다.

*아래 이미지를 보자. *

주황색 영역부터 JVM의 영역이다. Class Library와 Java Byte Code가 JVM에게 전달되는데, JVM 내부적으로 Class Loader라는 녀석이 이것을 전달받는다.

1. Class Loader

*클래스로더는 실행에 필요한 모든 실행파일을(.class) 찾는다. *

클래스로더는 아래와 같은 계층구조를 갖는다. (Java8기준이며, Java 9부터는 … 3가지 기본클래스로더와 원칙은 유효하나 모듈시스템도입에 따라 구현내용이 바뀌었다고 합니다.)

1) Bootstrap ClassLoader

• 3가지 중 최상위 클래스이다.
• /jre/lib에 담긴 자바 라이브러리를 로딩한다.
• Native C로 구현됨.

2) Extension ClassLoader

• /jre/lib/ext 폴더에 담긴 자바의 확장 클래스파일을 로딩한다.
• Java로 구현됨.

3) Application ClassLoader

• -classpath(또는 -cp)폴더에 있는 클래스를 로딩한다.
• Java로 구현됨.
• 개발자가 직접 작성한 코드를 로딩한다.
  

위의 클래스들은 아래 3가지 원칙에 따라 동작한다.

• Delegation Principle 클래스로더는 상위 클래스로더로 로딩요청을 위임합니다. 부트스트랩 로더에서부터 로딩요청을 수행하고 하위 클래스로더로 요청을 넘깁니다.
• Visibility Principle 범위 규칙을 적용합니다. 하위클래스로더는 상위클래스로더의 클래스를 찾을 수 있지만 , 상위클래스로더는 하위클래스 로더가 로딩한 클래스를 사용할 수 없습니다.
• Uniqueness Principle 하위 클래스로더는 상위 클래스로더가 로딩한 클래스를 다시 로딩하지 않습니다.

2. 바이트 코드 검증 (Byte code verifier)

클래스 로더가 모든 실행 파일을 준비하면 이 파일의 코드가 올바른지 검증한다. 코드가 정해진 규칙에 따라 작성되었는지 등을 검증한다.

3. 기계어 코드로 변환

Java의 실행파일은 바이트코드이기 때문에 실행될 때 다시 한번 기계가 읽을 수 있는 형태로 인터프리터를 통해 해석된다.

JVM이 자바 실행파일을 기계어 코드로 변환하는 방식에는

• 인터프리터
• JIT (Just In Time) compiler 가 있다.

GC와 Execution Engine

• Garbage Collector : JVM은 Garbage Collector를 통해 메모리 관리 기능을 자동으로 수행한다. 애플리케이션이 생성한 객체의 생존 여부를 판단하여 더 이상 사용되지 않는 객체를 해제하는 방식으로 메모리를 자동 관리한다.
• Execution Engine : Class Loader를 통해 JVM 내의 런타임 데이터 영역에 배치된 바이트 코드를 실행한다. 이 때, Execution Engine은 자바 바이트 코드를 명령어 단위로 읽어서 실행한다.

Runtime Data Areas

JVM이 운영체제 위에서 실행되면서 할당받는 메모리 영역이다. Class Loader에서 준비한 데이터들을 보관하는 저장소이다.

1. Method (Static) Area

JVM이 읽어들인 클래스와 인터페이스에 대한 Runtime Constant Pool, 멤버 변수(필드), 클래스 변수(Static 변수), 생성자와 메소드를 저장하는 공간이다.

2. Runtime Constant Pool

• 메소드 영역에 포함되지만 독자적 중요성이 있다.
• 클래스 파일 constant_pool 테이블에 해당하는 영역이다.
• 클래스와 인터페이스 상수, 메소드와 필드에 대한 모든 레퍼런스를 저장한다.
• JVM은 Runtime Constant Pool을 통해 해당 메소드나 필드의 실제 메모리 상 주소를 찾아 참조한다.

※ 메소드 영역/런타임 상수 풀의 사용기간 및 스레드 공유 범위

• JVM 시작시 생성
• 프로그램 종료 시까지
• 명시적으로 null 선언 시
• 구성 방식이나 GC 방법은 JVM 벤더마다 다를 수 있다.

3. Heap Area

• JVM이 관리하는 프로그램 상에서 데이터를 저장하기 위해 런타임 시 동적으로 할당하여 사용하는 영역이다.
• New 연산자로 생성된 객체 또는 객체(인스턴스)와 배열을 저장한다.
• 힙 영역에 생성된 객체와 배열은 스택 영역의 변수나 다른 객체의 필드에서 참조한다.
• 참조하는 변수나 필드가 없다면 의미 없는 객체가 되어 GC의 대상이 된다.
• 힙 영역의 사용기간 및 스레드 공유 범위
  • 객체가 더 이상 사용되지 않거나 명시적으로 null 선언 시
  • GC(Garbage Collection) 대상
  • 구성 방식이나 GC 방법은 JVM 벤더마다 다를 수 있다.
  • 모든 스레드에서 공유한다.

4. Stack Area

• 각 스레드마다 하나씩 존재하며, 스레드가 시작될 때 할당된다.
• 메소드를 호출할 때마다 프레임(Frame)을 추가(push)하고 메소드가 종료되면 해당 프레임을 제거(pop)하는 동작을 수행한다.
• 선입후출(FILO, First In Last Out) 구조로 push와 pop 기능 사용
• 메소드 호출 시 생성되는 스레드 수행정보를 기록하는 Frame을 저장
• 메소드 정보, 지역변수, 매개변수, 연산 중 발생하는 임시 데이터 저장
• 기본(원시)타입 변수는 스택 영역에 직접 값을 가진다.
• 참조타입 변수는 힙 영역이나 메소드 영역의 객체 주소를 가진다.

5. PC Register

• Thread가 생성될 때마다 생기는 공간으로 Thread가 어떠한 명령을 실행하게 될지에 대한 부분을 기록한다.
• JVM은 Stack-Base 방식으로 작동한다.
• JVM은 CPU에 직접 Instruction을 수행하지 않고, Stack에서 Operand를 뽑아내 이를 별도의 공간에 저장하는 방식을 취하는데, 이러한 메모리 공간을 PC Register라고 한다.

6. Native Method Stack Area

• 자바 외 언어로 작성된 네이티브 코드를 위한 Stack이다.
• 즉, JNI(Java Native Interface)를 통해 호출되는 C/C++ 등의 코드를 수행하기 위한 스택이다.
• 네이티브 메소드의 매개변수, 지역변수 등을 바이트 코드로 저장한다.

참고했습니다.

• https://hoonmaro.tistory.com/19 [훈마로의 보물창고]
• https://medium.com/pocs/jvm%EC%9D%B4-%EC%9E%90%EB%B0%94%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%A8%EC%9D%84-%EC%8B%A4%ED%96%89%ED%95%98%EB%8A%94-%EA%B3%BC%EC%A0%95-3ac22cb22916
• https://ifcontinue.tistory.com/9
• https://www.holaxprogramming.com/2013/07/16/java-jvm-runtime-data-area/

HotSpot? 핫스팟?🤔

사실 HotSpot이라는 단어를 들었을 때 가장 먼저 떠오른 의미는

핫스팟 또는 핫스폿(영어: hotspot)은 스마트폰, 노트북을 포함한 이동 단말기로 라우터 등 무선 액세스 포인트가 설치된 지역에서 무선 네트워크(WLAN)에 접속하여 초고속 인터넷과 각종 콘텐츠를 이용할 수 있게 하는 서비스

그동안 인터넷 와이파이 관련된 핫스팟만 알았지.. JVM을 말하는 것인 줄은 이번에 알았다...

나란 🐕발자.. 참 대단합니다... 허허허

근데 막상 알아보니 HotSpot이라는 단어를 JVM에 사용한 이유가 생각보다 단순하다.

JDK1.3 전에 나왔던 가상 머신과 구분하기 위한 이름이라고 생각하면 된다. 참고로 자바를 만드는 오라클 사이트에서는 이전 버전의 JVM을 Classic VM이라고 표현하고 있다.

JVM에 대한 설명은 이미 훌륭하게 정리된 글의 링크를 참조하도록 하자.

HotSpot JVM에서는 두 가지의 컴파일러가 제공된다.

• 클라이언트 컴파일러
• 서버 컴파일러

불과 몇년 전만 하더라도 많은 CPU코어를 사용할 수 없었고 대부분 코어의 개수가 하나였다. 이런 사용자의 상황을 위해 만들어진 것이 클라이언트 컴파일러였다.

클라이언트 컴파일러의 간단한 특징을 보자면,

• 애플리케이션 시작 시간을 빠르게 하기 위해 만들었다.
• 적은 메모리를 점유하도록 했다.
• 애플리케이션 수행 속도에 중점을 뒀다.
• 서버 컴파일러보다 먼저 컴파일을 시작한다.
• 최적화를 위한 대기시간이 짧다.
• Start-Up 시간이 빠르다. 하지만 최적화가 덜하기 때문에 코드실행은 서버가 더 빠르다.

서버 컴파일러의 특징은 아래와 같다.

• 컴파일전에 많은 정보를 수집하여 최적화에 중점을 둔다
• 서버 컴파일러는 절대로 모든 코드를 컴파일하지 않는다

*그렇다면 클라이언트/서버 컴파일러의 구분 기준은 뭘까? *

• 2개 이상의 물리적 프로세서
• 2GB 이상의 물리적 메모리

위의 조건에 만족하면 Oracle에서 만든 JVM은 서버 컴파일러를 선택한다.

명시적으로 컴파일러를 지정하려면 아래와 같이 java 명령과 클래스 이름 사이에 옵션을 추가하면 된다.

java -server 클래스명 java -client 클래스명

JIT?

JIT는 JVM내부에서 바이트코드를 기계어로 변환하는 방식으로서 Just-In-Time의 약자다.

• 아래 그림에서 컴파일된 ByteCode와 기계코드 사이에 있는 JVM에서 JIT가 수행된다. 이미지 출처 : https://images.app.goo.gl/LsXuRMLSYmfSDWzQ9

컴파일 방식

컴파일 방식은 인터프리트 방식과 정적 컴파일 방식이 있다.

• 인터프리트 방식 : 프로그램 실행시마다 기계어로 변환하는 작업을 수행하는 방식
• 정적 컴파일 방식 : 실행 전 기계어로 미리 변환 후 실행하는 방식이며, 딱 한번만 수행된다.

JIT는 이 두가지를 혼합한 것이다. 인터프리터에 의해 변환이 지속적으로 수행되지만, 필요한 코드 정보는 캐시에 담아두었다가(메모리에 올려둠) 재사용하는 방식이다.

장점

반복적으로 수행되는 코드에 대해 매우 빠른 성능을 보인다.

단점

처음 시작 시에 변환 단계를 거치기 때문에 성능이 느리다. (하지만 최근에는 CPU성능과 JDK성능이 개선되어 많이 개선됐다고 한다. )

위의 내용에서 JVM -> 기계코드로 변환되는 부분에서 JIT가 수행된다.

출처 : 『JAVA의 신』 - 이상민 저

급기야 N년차에는 저렇게 되지 말아야지 하고 다짐했던 부분들이 나에게 고스란히 나타났다...ㅠㅠ

그거슨 기본기 부족...

개발자로서 취직 후 열심히 산다고 살았는데... 상황에 따라 급한 것에만 치중하다보니 이런 사태가 벌어진 것 같다. 장기적인 시각으로 개발자로서 앞으로 살아가려면 지금의 실력으로는 갈 곳이 없ㅇ....

결국 현실을 자각하여

천리길도 한걸음부터의 마음으로 JAVA 기본서를 진지하게 다시 보기로 결심했다.

*초조함과 불안을 에너지삼아서라도 한단계 성장하는 계기가 되기를 기도하며 JAVA개발자로서 꼭 알아야 할 내용들을 이곳에 정리해보고자 한다. *