🖥️ JDK (Java Development Kit)

JDK는 Java 애플리케이션 개발에 사용할 수 있는 SDK(Software Development Kit)이다.

💡 SDK?
Software Development Kit (소프트웨어 개발 키트) 로, 애플리케이션을 처음부터 효율적으로 개발할 수 있도록 코드를 처음부터 작성하는 대신 라이브러리, 컴파일러, 디버거, 코드 샘플 및 문서로 구성된 통합 플랫폼을 제공한다.
SDK의 대표적인 예로, 안드로이드 스튜디오 등이 있다.

JDK안에는 자바 개발 시 필요한 라이브러리들과 javac, javadoc 등의 개발 도구들이 포함되어 있고, 개발을 하려면 자바 프로그램을 실행도 시켜줘야 하기 때문에 뒤에서 배울 JRE(Java Runtime Environment)도 함께 포함되어 있다.

자바로 만든 프로그램을 실행만 하기 위해서는 JRE만 있으면 되지만, 자바로 프로그램을 만들기 위해선 소스코드(*.java)를 바이트 코드로(*.class)로 바꿔주는 JDK에 존재하는 컴파일러(javac)가 필요하므로 JDK 가 필수적이다

아래 그림에서 볼수 있듯이 JDK는 JVM, JRE를 모두 포함하고, 이외에 자바를 개발 하는데 필요한 development tools 도 포함하고 있는 걸 알 수 있다.

---

🖥️ JRE (Java Runtime Environment)

JRE에 대해 자세히 알기 전에 Java의 장점에 대해 미리 알아보자

Java의 강점이 무엇일까

여러가지가 있겠지만 그 중 하나는 플랫폼 독립적이라는 점이다.
즉, 특정 OS에서 작성된 자바 프로그램을 특별한 코드 수정 없이 타 OS에서도 실행이 가능하다는 점이다

이것이 가능하게 되는 이유가 바로 JRE이다.

JRE에 대한 aws의 공식문서 설명은 아래와 같다

JRE는 Java 프로그램이 올바르게 실행되기 위해 필요한 소프트웨어입니다. Java는 여러 최신 웹 및 모바일 애플리케이션의 기반이 되는 컴퓨터 언어입니다. JRE는 Java 프로그램과 운영 체제 간의 통신을 위한 기본 기술입니다. JRE는 Java 소프트웨어 작성 시 추가 수정 없이 어떤 운영 체제에서도 실행되도록 모든 리소스를 제공하는 번역기 및 촉진자 역할을 합니다.

엄밀히 말하면 추가 수정 없이 어떤 운영 체제에서도 실행되도록 하는 역할은 JRE에 포함된 JVM의 역할이다. JVM에 대해서는 뒤에서 더 구체적으로 알아보도록 하자.

간단히 정리하자면, JRE는 클래스 라이브러리, 지원 파일 및 JVM이 포함된 패키지이고, 컴파일 된 Java 프로그램을 실행시키려면 JRE가 필요하다고 보면 된다.

---

🖥️ JVM (Java Virtual Machine)

JVM은 자바 가상머신(Java Virtual Machine)의 약자로서, Java 프로그램을 실행하는 소프트웨어이다.
자바로 작성된 모든 프로그램은 JVM에서만 실행될 수 있으므로, 자바 프로그램을 실행하기 위해서는 반드시 JVM이 설치되어 있어야 한다.

앞서 말했듯이 JVM은 JRE에 포함되어 있다. 그래서 현재 사용하는 컴퓨터의 운영체제에 맞는 JRE가 설치되어 있다면 JVM이 설치되어 있다는 뜻이기도 하다.

JAVA라는 프로그래밍 언어가 인기 있는 핵심 이유중 하나가 바로 이 JVM 개념인데,
JVM을 사용함으로써 얻는 가장 큰 이점은 JVM을 사용하면 자바 프로그램을 모든 플랫폼에서 제약 없이 동작하도록 할 수 있다는 점이다.

다만, JVM은 바이트코드(*.class)를 각 OS별로 다른 기계어(Binary Code)로 변역해야 한다.
이것이 OS별로 설치하는 JDK(Java Development Kit)가 다른 이유이다.

또한 JVM은 자바 프로그램의 메모리를 가비지 컬렉션을 통해 효율적으로 관리해 준다.

---

🦾 JVM의 구조

JVM는 크게 3가지 핵심 구성 요소로 이루어져있다.

• 클래스로더 (ClassLoader)

• 실행 엔진 (Execution Engine)

• 런타임 데이터 영역 (Runtime Data Area)

---

클래스로더 (ClassLoader)

클래스 로더는 JVM 내로 바이트 코드(*.class)를 동적으로 로드하고, 링크를 통해 배치하는 작업을 수행하는 모듈이다.

즉, 로드된 바이트 코드(.class)들을 엮어서 JVM의 메모리 영역인 Runtime Data Area에 배치한다.

클래스를 메모리에 올리는 로딩 기능은 한번에 메모리에 올리지 않고, 어플리케이션에서 필요한 경우 동적으로 메모리에 적재하게 된다.

클래스 파일의 로딩 순서는 다음과 같이 3단계로 구성된다. (Loading → Linking → Initialization)

• Loading(로드) : 클래스 파일을 가져와서 JVM의 메모리에 로드한다.
• Linking(링크) : 클래스 파일을 사용하기 위해 검증하는 과정이다.
  - Verifying(검증) : 읽어들인 클래스가 JVM 명세에 명시된 대로 구성되어 있는지 검사한다.
  - preparing(준비) : 클래스가 필요로 하는 메모리를 할당한다.
  - Resolving(분석) : 클래스의 상수 풀 내 모든 심볼릭 레퍼런스를 다이렉트 레퍼런스로 변경한다.

  💡심볼릭 참조(symbolic reference)와 직접 참조(direct reference)
  심볼릭 참조(symbolic reference)란 우리가 코드를 작성하면서 사용한 class, field, method의 이름을 지칭한다. Resolving 단계는 class, field, method 그리고 constant pool의 symbolic references를 실제 메모리 주소로 변환한다.

• Initialization(초기화) : 클래스 변수들을 적절한 값으로 초기화한다. ( static 필드들을 설정된 값으로 초기화 등 )

---

실행 엔진 (Execution Engine)

실행 엔진은 클래스 로더를 통해 런타임 데이터 영역에 배치된 바이트 코드를 명령어 단위로 읽어서 실행한다

자바 바이트 코드(*.class)는 기계가 바로 수행할 수 있는 언어보다는 가상머신이 이해할 수 있는 중간 레벨로 컴파일 된 코드이다. 그래서 실행 엔진은 이와 같은 바이트 코드를 실제로 JVM 내부에서 기계가 실행할 수 있는 형태로 변경해준다.

이 수행 과정에서 실행 엔진은 인터프리터와 JIT 컴파일러 두 가지 방식을 혼합하여 바이트 코드를 실행한다.

✏️ 인터프리터(Interpreter)

바이트 코드 명령어를 하나씩 읽어서 해석하고 바로 실행한다.
JVM안에서 바이트코드는 기본적으로 인터프리터 방식으로 동작한다. 
다만 같은 메소드 라도 여러번 호출이 된다면 매번 해석하고 수행해야 되서 전체적인 속도는 느리다.

---

✏️ JIT 컴파일러(Just-In-Time Compiler)

위의 Interpreter의 단점을 보완하기 위해 도입된 방식으로, 반복되는 코드를 발견하여 바이트 코드 전체를 컴파일하여 Native Code로 변경하고 이후에는 해당 메서드를 더 이상 인터프리팅 하지 않고 캐싱해 두었다가 네이티브 코드로 직접 실행하는 방식이다.

하나씩 인터프리팅하여 실행하는것이 아니라, 컴파일된 네이티브 코드를 실행하는 것이기 때문에 전체적인 실행 속도는 인터프리팅 방식보다 빠르다.

하지만 바이트코드를 Native Code로 변환하는 데에도 비용이 소요되므로, JVM은 모든 코드를 JIT 컴파일러 방식으로 실행하지 않고 인터프리터 방식을 사용하다 일정 기준이 넘어가면 JIT 컴파일 방식으로 명령어를 실행하는 식으로 진행한다.

---

✏️ 가비지 컬렉터 (Garbage Collector ,GC)

자바 가상 머신은 가비지 컬렉터(garbage collector)를 이용하여 Heap 메모리 영역에서 더는 사용하지 않는 메모리를 자동으로 회수해 준다.

C언어 같은 경우 직접 개발자가 메모리를 해제해줘야 되지만, JAVA는 이 가비지 컬렉터를 이용해 자동으로 메모리를 실시간 최적화 시켜준다.

따라서 개발자가 따로 메모리를 관리하지 않아도 되므로, 더욱 손쉽게 프로그래밍을 할 수 있도록 해준다.

일반적으로 자동으로 실행되지만, 단 GC(가비지 컬렉터) 가 실행되는 시간은 정해져 있지 않다.
특히 Full GC 가 발생하는 경우, GC 를 제외한 모든 스레드가 중지되기 때문에 장애가 발생할 수 있다.

---

런타임 데이터 영역 (Runtime Data Area)

런타입 데이터 영역은 쉽게 말하면 JVM의 메모리 영역으로 자바 애플리케이션을 실행할 때 사용되는 데이터들을 적재하는 영역이다.

런타임 데이터 영역은 위 그림과 같이 크게 Method Area, Heap Area, Stack Area, PC Register, Native Method Stack로 나눌 수 있다.

이때 Method Area, Heap Area 는 모든 쓰레드(Thread)가 공유하는 영역이고, 나머지 Stack Area, PC Register, Native Method Stack 은 각 쓰레드 마다 생성되는 개별 영역이다.

따라서 위의 그림을 좀더 자세히 표현하자면 다음과 같은 도식이 된다.

---

✏️ 메서드 영역 (Method Area)

메서드 영역은 JVM이 시작될 때 생성되는 공간으로 바이트 코드(.class)를 처음 메모리 공간에 올릴 때 초기화되는 대상을 저장하기 위한 메모리 공간이다.
JVM이 동작하고 클래스가 로드될 때 적재되서 프로그램이 종료될 때까지 저장 된다.

💡 Tip
메서드 영역(Method Area) 은 Class Area 나 Static Area 로도 불리운다.

모든 쓰레드가 공유하는 영역이라 다음과 같이 초기화 코드 정보들이 저장되게 된다.

• Field Info : 멤버 변수의 이름, 데이터 타입, 접근 제어자의 정보
• Method Info : 메소드 이름, return 타입, 함수 매개변수, 접근 제어자의 정보
• Type Info : Class 인지 Interface 인지 여부 저장, Type의 속성, 이름 Super Class의 이름

간단히 말하자면 메서드 영역에는 정적 필드와 클래스 구조만을 갖고 있다고 할수있다.

💡 런타임 상수풀 (Runtime Constant Pool)

• 메서드 영역에 존재하는 별도의 관리영역.
• 각 클래스/인터페이스 마다 별도의 constant pool 테이블이 존재하는데, 클래스 생성할때 참조해야할 정보들을 상수로 가지고 있는 영역이다.
• JVM은 이 Constant Pool을 통해 해당 메소드나 필드의 실제 메모리 상 주소를 찾아 참조한다.
• 정리하면 상수 자료형을 저장하여 참조하고 중복을 막는 역할을 수행한다.

---

✏️ 힙 영역 (Heap Area)

힙 영역은 메서드 영역와 함께 모든 쓰레드가 공유하며, JVM이 관리하는 프로그램 상에서 데이터를 저장하기 위해 런타임 시 동적으로 할당하여 사용하는 영역이다.

즉, new 연산자로 생성되는 클래스와 인스턴스 변수, 배열 타입 등 Reference Type이 저장되는 곳이다.

당연히 Method Area 영역에 저장된 클래스만이 생성이 되어 적재된다.

💡 Info
※ 힙 영역의 사용기간

• 객체가 더 이상 사용되지 않거나 명시적으로 null 선언되기 전 까지
• GC(Garbage Collection) 대상으로 선정되기 전 까지

유의할점은 힙 영역에 생성된 객체와 배열은 Reference Type으로서, JVM 스택 영역의 변수나 다른 객체의 필드에서 참조된다는 점이다.

즉, 힙의 참조 주소는 "스택"이 갖고 있고 해당 객체를 통해서만 힙 영역에 있는 인스턴스를 핸들링할 수 있는 것이다.

만일 참조하는 변수나 필드가 없다면 의미 없는 객체가 되기 때문에 이것을 쓰레기로 취급하고 JVM은 쓰레기 수집기인 Garbage Collector를 실행시켜 쓰레기 객체를 힙 영역에서 자동으로 제거된다.

이처럼 힙 영역은 가비지 컬렉션에 대상이 되는 공간이다.
그리고 효율적인 가비지 컬렉션을 수행하기 위해서 세부적으로 다음과 같이 5가지 영역으로 나뉘게 된다.

---

Java8 이전까지의 Heap 메모리 구조

이렇게 다섯가지 영역(Eden, survivor 0, survivor 1, Old, Permanent)으로 나뉜 힙 영역은 다시 물리적으로 Young Generation 과 Old Generation 영역으로 구분되게 되는데 다음과 같다.

• Young Generation : 생명 주기가 짧은 객체를 GC 대상으로 하는 영역.
  • Eden : new를 통해 새로 생성된 객체가 위치. Eden 영역에 데이터가 가득 차면, Eden 영역에 있던 객체가 Survivor1 또는 Survivor2로 옮겨진다
  • Survivor 0 / Survivor 1 : 각 영역이 채워지게 되면, 남은 객체는 비워진 Survivor로 순차적으로 이동. 이 두 개의 영역 사이에 우선순위가 있는 것은 아니다.

• Old Generation : 생명 주기가 긴 객체를 GC 대상으로 하는 영역. Youn Generation에서 마지막까지 살아남은 객체가 이동
  • 단, Young 영역에서 Old 영역으로 넘어가는 객체 중, Survivor 영역을 거치지 않고 Eden 영역에서 바로 Old 영역으로 넘어가는 객체도 존재하는데, 이는 객체의 크기가 아주 클 경우 발생한다. 예를들어 Survivor영역의 크기가 16MB인데 객체의 크기가 20MB일 경우에 해당한다.

💡 오랫동안 살아남은 객체들이라면, 얼마나 오랫동안일까?

오래되었다고 하는 기준은 Young Generation 영역에서 Minor GC 가 발생하는 동안 얼마나 오래 살아남았는지로 판단한다. 각 객체는 Minor GC에서 살아남은 횟수를 기록하는 age bit 를 가지고 있으며, Minor GC가 발생할 때마다 age bit 값은 1씩 증가 하게되며, age bit 값이 MaxTenuringThreshold 라는 설정값을 초과하게 되는 경우 Old Generation 영역을 객체가 이동 되는 것이다. 또는 Age bit가 MaxTenuringThreshold 초과하기 전이라도 Survivor 영역의 메모리가 부족할 경우에는 미리 Old Generation 으로 객체가 옮겨질 수도 있다.

Old 영역에서는 2차 GC인 Major GC(FULL GC)가 일어나게 되며 GC를 진행하는 Thread를 제외하고 이외의 모든 Thread를 멈춘 상태로 GC가 진행된다. 이와 같이 GC를 진행하는 Thread 이외에 모든 Thread를 멈추는 상태를 Stop-the-world라고 하며, 어떠한 GC알고리즘을 사용하더라고 Stop-the-World 상태를 피할수는 없다.

JVM에 대해서 자세히 공부하고 있다면 GC튜닝에 대해서 들어본 적이 있을것이다. GC를 튜닝하는 이유가 바로 Stop-thr-world의 시간을 최소한으로 줄이기 위함이다.

---

Java8 이후의 Heap 메모리 구조

위에서 Heap메모리 구조를 설명하면서 설명하지 않은 영역이 하나 있다. 바로 Permanent 영역이다.

Permanent 영역의 경우 Java8부터 Metaspace 영역으로 변경되었다. 기존의(자바8 이전) Permanet 영역에는 다음과 같은 정보들이 저장되었다.

• Class의 메타데이터 (바이트코드 포함)
• Method의 메타데이터
• static 객체, static 상수
• 상수화된 String Object
• Class와 관련된 배열 객체 메타데이터
• JVM 내부적인 객체들과 JIT의 최적화 정보

이러한 데이터들을 저장하던 Permanent 영역을 자바8에서부터는 Metaspace라는 영역으로 대체하였고, 이 Metaspace영역은 Native메모리 영역으로 JVM이 아닌 OS에 의해 관리되도록 변경되었다.

• Class의 메타데이터 (바이트코드 포함) → MetaSpace로 이동
• Method의 메타데이터 → MetaSpace로 이동
• static 객체,static 변수 (class variable) → Heap으로 이동
• 상수화된 String Object → Heap으로 이동
• Class와 관련된 배열 객체 메타데이터 → Metaspace로 이동
• JVM 내부적인 객체들과 JIT의 최적화 정보 → Metaspace로 이동

즉, 자바8 이후부터 Static Object가 Heap 영역으로 옮겨져서 GC의 대상이 될 수 있게 하였다.

거의 그럴일은 없지만 가끔씩 Collection 객체를 static하게 구현하여 값을 계속해서 추가하다가 Perm영역이 가득차서 OutOfmemoryerror permgen space 라는 Error를 경험할 수도 있다.

static List<Object> list = new ArrayList<>();

즉, 이러한 OOM 에러가 발생하는 현상을 개선하기 위해 기존에 Perm 영역에 저장되던 static Obejct의 변수와, 상수화된 static Object를 Heap영역으로 이동시켜 GC의 대상이 되도록 변경하고, 메타데이터 정보들을 OS가 관리하는 영역으로 옮겨 Perm 영역의 사이즈 제한을 없앤 것이라고 할 수 있다.

"Metaspace 영역은 Heap이 아닌 Native 메모리 영역안에 있다. Heap 영역은 JVM이 관리하고 Native 영역은 OS레벨에서 관리해 자동으로 크기를 조절하고, Metaspace가 Native 메모리를 사용함으로써 개발자는 메모리에서의 영역확보의 상한을 크게 인식할 필요가 없게 되었다. 이것이 Java 8에서 Metaspace가 도입된 이유이다."

---

✏️ 스택 영역 (Stack Area)

스택 영역은 int, long, boolean 등 기본 자료형을 생성할 때 저장하는 공간으로, 임시적으로 사용되는 변수나 정보들이 저장되는 영역이다.

자료구조 Stack은 마지막에 들어온 값이 먼저 나가는 LIFO  구조로 push와 pop 기능 사용방식으로 동작한다.

메서드 호출 시마다 각각의 스택 프레임(그 메서드만을 위한 공간)이 생성되고 메서드 안에서 사용되는 값들을 저장하고, 호출된 메서드의 매개변수, 지역변수, 리턴 값 및 연산 시 일어나는 값들을 임시로 저장한다.

그리고 메서드 수행이 끝나면 프레임별로 삭제된다.

💡 스택 프레임(stack frame)
메소드가 호출될 때마다 프레임이 만들어지며, 현재 실행중인 메소드 상태 정보를 저장하는 곳이다. 메서드 호출 범위가 종료되면 스택에서 제거된다. 스택 프레임에 쌓이는 데이터는 메서드의 매개변수, 지역변수, 리턴값, 연산시 결과값 등이 있다.

단, 데이터의 타입에 따라 스택(stack) 과 힙(haeap)에 저장되는 방식이 다르다는 점은 유의해야 한다.

• 기본(원시)타입 변수는 스택 영역에 직접 값을 가진다.
• 참조타입 변수는 힙 영역이나 메소드 영역의 객체 주소를 가진다.

예를들어 Person p = new Person(); 와 같이 클래스를 생성할 경우, new 에 의해 생성된 클래스는 Heap Area 에 저장되고, Stack Area 에는 생성된 클래스의 참조인 p 만 저장된다.

스택 영역은 각 스레드마다 하나씩 존재하며, 스레드가 시작될 때 할당된다.

프로세스가 메모리에 로드 될 때 스택 사이즈가 고정되어 있어, 런타임 시에 스택 사이즈를 바꿀 수는 없다.

만일 고정된 크기의 JVM 스택에서 프로그램 실행 중 메모리 크기가 충분하지 않다면 StackOverFlowError가 발생하게 된다.

쓰레드를 종료하면 런타임 스택도 사라진다.

여기까지 배운 메소드 영역, 힙 영역, 스레드 영역을 한 그림으로 표시하자면 다음과 같이 도식이 그려지게 된다.

---

✏️ PC 레지스터 (Program Counter Register)

PC Register에는 멀티 쓰레드 프로그래밍 환경에서 한 쓰레드가 작업을 하다가 다른 쓰레드로 CPU자원을 넘겨주고 다시 받았을 때, 이어서 작업을 하기 위해 현재 실행중인 명령어의 주소를 기록한다.

PC Register는 쓰레드가 시작될 때 생성되어 각 쓰레드 별로 하나씩 존재한다.

JVM 명령의 주소는 쓰레드가 어떤 부분을 무슨 명령으로 실행해야할 지에 대한 기록을 가지고 있다.

만약 쓰레드가 JVM Instruction을 수행중이라면 Instruction의 주소를 가지고 있지만, Native Method를 수행중이라면 PC Register는 Undefined상태로 남아있고, 이에 대한 처리는 바로 뒤에 언급하게 될 Native Method Stack에서 담당한다

---

✏️ 네이티브 메서드 스택 (Native Method Stack)

네이티브 메서드 스택는 자바 코드가 컴파일되어 생성되는 바이트 코드가 아닌 실제 실행할 수 있는 기계어로 작성된 프로그램을 실행시키는 영역이다.

또한 자바 이외의 언어(C, C++, 어셈블리 등)로 작성된 네이티브 코드를 실행하기 위한 공간이기도 하다.

사용되는 메모리 영역으로는 일반적인 C 스택을 사용한다.

위에서 배운 JIT 컴파일러에 의해 변환된 Native Code 역시 여기에서 실행이 된다고 보면 된다. (아직 이해가 안되면 실행 엔진 섹션 부분을 다시 복습하고 오자)

일반적으로 메소드를 실행하는 경우 JVM 스택에 쌓이다가 해당 메소드 내부에 네이티브 방식을 사용하는 메소드가 있다면 해당 메소드는 네이티브 스택에 쌓인다.

그리고 네이티브 메소드가 수행이 끝나면 다시 자바 스택으로 돌아와 다시 작업을 수행한다.

그래서 네이티브 코드로 되어 있는 함수의 호출을 자바 프로그램 내에서도 직접 수행할 수 있고 그 결과를 받아올 수도 있는 것이다.

네이티브 메소드 스택은 바로 다음에 배울 네이티브 메소드 인터페이스(JNI)와 연결되어 있는데, JNI가 사용되면 네이티브 메서드 스택에 바이트 코드로 전환되어 저장되게 된다.

---

✏️ JNI (Java Native Interface)

JNI는 자바가 다른 언어로 만들어진 어플리케이션과 상호 작용할 수 있는 인터페이스 제공하는 프로그램이다.
위에서 다뤄봤듯이, JNI는 JVM이 Native Method를 적재하고 수행할수 있도록 한다.
하지만 실질적으로 제대로 동작하는 언어는 C / C++ 정도 밖에 없다고 한다.

---

✏️ Native Method Library

C, C++로 작성된 라이브러리를 칭한다.
만일 헤더( *.h )가 필요하면 JNI는 이 라이브러리를 로딩해 실행한다.

---

🖥️ Java SE (Java Standard Edition)

가장 기본이 되는 표준 에디션의 자바 플랫폼으로 자바 언어의 핵심 기능을 제공

• 가장 기본적인 클래스 패키지로 구성

• PC용 어플리케이션, 어플리케이션 개발, 응용프로그램 개발, 웹 개발, 안드로이드 개발 등등

• PC에 설치하여 사용할 수 있는 모든 프로그램 개발에 관련

  ---

🖥️ Java EE (Java Enterprise Edition)

대규모 기업용 에디션 으로서 SE의 확장판(대규모 트래픽의 프로그램 개발 시)

• 기업 환경을 위한 대규모 솔루션 개발, 모바일폰, 셋탑 박스, 차량용 텔레매틱스 시스템 개발

• ex) Servlet, JSP, EJB...

  ---

🖥️ Java ME (Java Micro Edition)

피쳐폰, PDA폰, 셉톱박스, 프린터와 같은 작은 임베디드 기기들 같은 작은 기기를 다루는데 이용하는 에디션

• JAVA SE를 줄여 라이트하게 만든 것이 므로 SE개발을 할 줄 알면 ME기반의 개발도 가능
• 각각의 OS(ex. Android OS, IOS, Black Berry 등)를 가지고 있는 스마트 폰이 대중화된 지금은 잘 쓰이지 않는다

---

Reference

• JDK, JRE, JVM / JAVA SE, EE …
• JRE(Java Runtime Environment)란?
• Java 런타임 환경(JRE)이란 무엇인가요?
• [JAVA기초] JVM이란?
• SDK란 무엇인가요?
• SDK와 API의 차이점은 무엇인가요?
• ☕ JDK / JRE / JVM 개념 & 구성 원리 💯 총정리
• ☕ JVM 내부 구조 & 메모리 영역 💯 총정리
• #자바가상버신, JVM(Java Virtual Machine)이란 무엇인가?
• 차근차근 알아보는 Java 프로그램 실행 과정
• JAVA8 이후의 heap 메모리 구조와 GC 알고리즘
• JVM의 Java 8에서의 변화
• [JAVA] JVM - Runtime Data Area