인터뷰: Java에 능통, 인터뷰: JVM 가상 머신 메모리 모델의 하위 수준 원리에 대해 이야기하겠습니다. 자세히 설명하고 이유를 이해해야 합니다. 그것을 읽은 후 이력서에 Java를 능숙하게 쓸 수 있습니까?

자바에 능숙하십니까? 다음 底层中的底层原理을 알고 있는지 봅시다.
JVM에 관해서는 메모리 모델에 대해 이야기할 필요가 있는데, JVM 사양에 따르면 JVM 메모리는 虚拟机栈VM stack, 堆heap, 方法区Method Area, , 의 程序计数器Program Counter Register다섯 本地方法栈Native Method Stack부분 으로 나뉩니다. 아래 그림과 같이 이 5가지 영역의 원리를 자세히 설명하겠습니다. (독자의 시간을 절약하고 모든 사람의 이해와 기억을 용이하게 하기 위해 저자는 모든 지식 포인트를 레이어와 세그먼트로 나누고 더 짧은 언어를 사용하여 간결하고 포괄적으로 설명하고 모든 문장이 핵심입니다.)

여기에 이미지 설명 삽입

1. 가상 머신 스택(VM 스택)

  • 각 스레드에는 스레드가 생성될 때 생성되는 개인 스택이 있습니다.

  • StackOverflowError 및 OutOfMemoryError 예외를 throw할 수 있습니다.

    • 스레드가 요청한 스택 크기가 가상 머신 스택이 허용하는 최대 크기를 초과하면 Java 가상 머신은 스택 오버플로 오류 예외를 발생시킵니다.
    • 가상 머신 스택을 동적으로 확장할 수 있고 확장을 시도할 때 충분한 메모리를 적용할 수 없거나 새 스레드를 생성할 때 해당 가상 머신 스택을 생성하기에 메모리가 충분하지 않으면 Java 가상 머신은 OutOfMemoryError를 발생시킵니다. 예외.
  • 메소드 호출 관련 지식:

    • 메서드가 호출되면 스택 프레임이 생성되어 가상 머신 스택에 푸시되고, 메서드가 실행된 후에는 스택 프레임이 스택에서 팝되고 소멸됩니다.
    • 스택에 저장되는 것은 "스택 프레임"이라는 것입니다. 각 메소드는 스택 프레임을 생성합니다. 스택 프레임 구조는 로컬 변수 테이블(기본 데이터 유형 및 객체 참조), 피연산자 스택, 메소드 종료 등으로 나뉩니다. 정보.
    • 디버그할 때 아래와 같이 프레임을 명확하게 볼 수 있습니다.
      여기에 이미지 설명 삽입
      해당 회로도는 다음과 같습니다.
      여기에 이미지 설명 삽입
  • 메서드의 모든 로컬 변수가 여기에 저장되기 때문에 스택 메모리는 가상 머신 스택의 스택 프레임에 있는 로컬 변수 테이블을 참조합니다.

  • 스택의 크기는 고정되거나 동적으로 확장될 수 있습니다. 스택 호출 깊이가 JVM에서 허용하는 범위보다 크면 StackOverflowError 오류가 발생하지만 이 깊이 범위는 고정된 값이 아닙니다(vmoptions 파일의 매개변수를 변경하여 크기를 조정할 수도 있습니다. 참조 자세한 내용은 이 기사 끝에 있는 부록, 여기에서 확장하지 않겠습니다.), 다음 코드로 테스트할 수 있습니다.

public class HeapDeepDemo {
    
    

    private static int index = 0;

    public void addIndex() {
    
    
        index++;
        addIndex();
    }


    public static void main(String[] args) {
    
    

        HeapDeepDemo heapDeepDemo = new HeapDeepDemo();

        try {
    
    
            heapDeepDemo.addIndex();
        } catch (Error e) {
    
    
            System.out.println("Stack deep : " + index);
            e.printStackTrace();
        }
    }
}

네 가지 실행의 결과는 다음과 같이 다릅니다.
여기에 이미지 설명 삽입여기에 이미지 설명 삽입
여기에 이미지 설명 삽입

여기에 이미지 설명 삽입


2. 네이티브 메소드 스택

자바 메소드에서 네이티브 메소드 스택을 호출하는 과정은 다음과 같다.
여기에 이미지 설명 삽입
네이티브 메소드 스택이란?

  • Native Method는 Java가 비 Java 코드를 호출하기 위한 인터페이스입니다. 메소드의 구현은 C 또는 C++와 같은 비 Java 언어로 구현됩니다. 그의 구체적인 접근 방식은 네이티브 메서드 스택에 네이티브 메서드를 등록하고 실행 엔진이 실행될 때 네이티브 메서드 라이브러리를 로드하는 것입니다.

네이티브 메소드 스택을 사용하는 이유는 무엇입니까?

  • 일부 작업을 자바로 구현하는 것이 쉽지 않거나, 프로그램의 효율성이 요구되는 경우, 때로는 자바 애플리케이션이 자바 외부 환경과 상호 작용해야 하는 경우가 있는데, 이것이 바로 네이티브 메소드가 존재하는 주된 이유입니다.

로컬 메소드 스택의 지식 포인트:

  • 위에서 VM 가상 머신 스택을 언급했는데, 가상 머신 스택은 자바 메소드의 호출을 관리하는 데 사용되며 로컬 메소드 스택은 각각의 역할을 수행하는 로컬 메소드의 호출을 관리하는 데 사용됩니다.
  • 가상 머신 스택 VM 스택과 마찬가지로 기본 메서드 스택도 스레드 전용입니다.
  • 가상 머신 스택 VM 스택과 마찬가지로 고정 또는 동적으로 확장 가능한 크기로 구현 가능
  • VM 스택과 마찬가지로 기본 메서드 스택도 StackOverflowError 및 OutOfMemoryError 예외를 throw할 수 있습니다.
    • 스레드가 요청한 스택 크기가 기본 메소드 스택이 허용하는 최대 크기를 초과하는 경우 Java 가상 머신은 스택 오버플로 오류 예외를 발생시킵니다.
    • 네이티브 메소드 스택이 동적으로 확장될 수 있고 확장을 시도할 때 충분한 메모리를 적용할 수 없거나 새 스레드를 생성할 때 해당 네이티브 메소드 스택을 생성하기에 메모리가 충분하지 않은 경우 Java 가상 머신은 OutOfMemoryError를 발생시킵니다. 예외.

3. 프로그램 카운터 레지스터

3.1 X86 아키텍처의 IP 명령어 포인터 레지스터에 대한 비유

프로그램 카운터는 어셈블리 및 마이크로 컴퓨터의 원리에서 X86 아키텍처의 CPU에 있는 IP 명령 포인터 레지스터와 유사하게 번역될 수도 있습니다 PC寄存器.자세한 내용은 내 다른 블로그( https://blog.csdn.net )를 참조하십시오. /MrYushiwen/article/details/ 122627634의 대략적인 내용은
다음과 같습니다.
여기에 이미지 설명 삽입

x86 아키텍처의 레지스터 다이어그램은 다음과 같습니다. (참고로 우리 대학 교과서에 있는 그림도 이렇게 그려져 있습니다. 그림은 영원하고 하나는 영원히 순환될 것입니다! 하하하)
여기에 이미지 설명 삽입

  • Java 1.2 이후 Linux의 JVM은 pthreads를 기반으로 구현되기 때문에 x86 아키텍처에서 ip 명령어 포인터 레지스터를 비교하는 이유는 무엇입니까?Java 스레드는 운영 체제에 의해 구현되고 Java 스레드는 항상 필요합니다. OS 쓰레드에 매핑되는 형태 중 하나, 매핑 모델은 1:1(네이티브 스레딩 모델), n:1(그린 쓰레드/유저 모드 스레딩 모델), m:n(하이브리드 모델) .
  • 현재 대부분의 플랫폼에서 1:1 모델을 사용합니다. 즉, 각 Java 스레드는 실행을 위해 OS 스레드에 직접 매핑됩니다. 이 시점에서 네이티브 메서드는 네이티브 플랫폼에서 직접 실행되며 추상 JVM 수준에서 "pc 레지스터"의 개념, 즉 네이티브 CPU의 실제 PC 레지스터가 무엇인지는 신경 쓸 필요가 없습니다. 현재 Java에서 스레드의 본질은 실제로 운영 체제의 스레드입니다.

3.2 JVM의 프로그램 카운터

  • JVM의 작은 메모리 공간으로 JVM은 동시에 실행되는 여러 스레드를 지원하며 각 스레드에는 자체 프로그램 카운터가 있습니다.
  • 그 역할은 현재 스레드가 실행하는 바이트코드의 줄 번호 표시기로 볼 수 있습니다. 가상머신의 개념적 모델에서는 바이트코드 인터프리터가 작동할 때 이 카운터의 값을 변경하여 실행할 다음 바이트코드 명령어를 선택합니다. 분기, 루프, 점프, 예외 처리, 스레드 복구 등의 기본 기능은 모두 이 카운터를 사용하여 완료하십시오.
  • 런타임 기능:
    • 스레드 생성으로 시작했습니다.
    • 스레드가 Java 메소드를 실행 중인 경우 이 카운터는 실행 중인 가상 머신 바이트코드 명령어의 주소를 기록합니다.
    • Native 메서드가 실행 중인 경우 이 기술의 값은 비어 있습니다(Undefined).
    • 이 메모리 영역은 Java Virtual Machine 사양에서 OutOfMemoryError 조건을 지정하지 않는 유일한 영역입니다.

4. 방법 영역

  • 메소드 영역은 모든 스레드가 공유합니다.
  • 클래스 정보, 상수, 정적 변수 및 가상 머신에 의해 로드된 Just-In-Time 컴파일러에 의해 컴파일된 코드와 같은 데이터를 저장하는 데 사용됩니다.
    여기에 이미지 설명 삽입
  • 메서드 영역은 논리적으로 힙의 일부이지만 힙과 구분하기 위해 일반적으로 "비힙"이라고 합니다.
  • 영구 생성(PermGen), 메소드 영역(Method Area) 및 메타 공간(Metaspace) 간의 관계:
    • 메서드 영역은 이 영역에 무엇을 저장할지 지정하는 사양 수준의 것입니다.PermGen과 Metaspace는 메서드 영역의 서로 다른 구현입니다.
    • 영구 생성(PermGen)은 Java7 및 이전 JVM의 메소드 영역(Method Area)을 구현한 것입니다.
    • 메타스페이스(Metaspace)는 메소드 영역(Method Area)에 대한 Java8 이상 JVM의 구현입니다.
    • 예를 들어 방법 영역은 휴대폰에 비유할 수 있고 불멸 벨트는 Nokia 휴대폰에 비유할 수 있고 메타스페이스는 Huawei 휴대폰에 비유할 수 있습니다.
  • Java 8에서 영구 세대(PermGen)를 Metaspace로 교체하는 이유:
    • 영구 생성의 크기에는 한계가 있는데, 너무 많은 클래스를 로드하면 영구 생성에서 메모리 오버플로우, 즉 java.lang.OutOfMemoryError: PermGen이 발생할 수 있으므로 JVM 개발자는 희망한다. 이 메모리 조각이 더 유연하게 관리되어 자주 나타나지 않도록 할 수 있습니다.
    • 영구 생성을 제거하면 JRockit에 영구 생성이 없기 때문에 HotSpot JVM을 JRockit VM과 쉽게 통합할 수 있습니다.
    • Java 7에서 인턴된 문자열은 더 이상 힙의 영구 생성에 할당되지 않고 힙의 주요 부분인 Young Generation과 Old Generation에 할당됩니다. Java8에서는 공식 문서에서 영구 생성 제거에 대해 언급했지만 인턴 문자열과 관련된 다른 변경 사항에 대해서는 언급하지 않았으므로 Java8에서는 문자열 상수 풀이 힙에 저장되어 있음을 알 수 있습니다.
    • 즉, Java8에서 메소드 영역은 원래 영구 생성에서 메타 공간(클래스 정보) 및 힙 구현(상수 풀, 정적 변수)의 두 부분으로 변경되었습니다. 힙에는 일반 객체와 상수 풀이 포함되어 있습니다. New String()이 힙에 삽입됩니다. String::intern 메소드는 먼저 힙의 상수 풀에서 이를 가져옵니다. 상수 풀에 상수 풀이 없으면 값 of String이 상수 풀에 저장되고 참조를 반환하고 다음에 String::intern 메소드가 호출될 때 상수 풀의 값이 직접 반환됩니다.
    • 영구 생성(PermGen)과 메타 공간(Metaspace)은 위에서 언급한 메소드 영역(메소드 영역)의 다른 구현이기 때문에 상수 풀이 Java8의 메소드 영역에 있다고 말할 수도 있습니다.
    • 메타 공간은 네이티브 메모리를 사용하여 구현되는데, 이는 메모리가 가상 머신에 있지 않다는 것을 의미하므로 이론적으로 물리적 머신은 JVM 자체에 제약을 받지 않고 여러 메모리 할당을 가질 수 있습니다.
    • Metaspace의 공간 점유율이 설정된 최대값에 도달하면 GC가 트리거되어 Dead Object 및 클래스 로더를 수집합니다.

5. 힙

Java7 및 이전 구조 다이어그램:
여기에 이미지 설명 삽입
4장 메서드 영역(메서드 영역)에서 Java8이 언급될 때 영구 생성(PermGen)이 Metaspace(Metaspace)로 대체되었으므로 Java8 및 이후 다이어그램은 다음과 같습니다.
여기에 이미지 설명 삽입

  • 힙이 세대별인 이유:

    • 생성의 유일한 이유는 GC 성능을 최적화하는 것입니다.
    • 생성이 없으면 모든 객체가 하나의 블록에 있고 GC에서 어떤 객체가 발견되는지 찾는 것은 쓸모가 없으므로 힙의 모든 영역을 스캔합니다. 그리고 많은 객체가 죽어가고 있습니다. 예를 들어, 젊은 세대의 객체는 기본적으로 죽었습니다(80% 이상). 따라서 젊은 세대의 가비지 수집 알고리즘은 복제 알고리즘을 사용합니다(향후 블로그 게시물을 작성할 것입니다. ). 세부 사항).
    • 세대별인 경우 새로 생성된 개체를 특정 위치에 놓고 먼저 GC 중에 "죽은" 개체가 저장되는 영역을 재활용하면 많은 공간이 확보됩니다.
  • 마이너 GC, 메이저 GC 및 전체 GC의 차이점:

    • Young GC(Eden 및 Survivor 영역 포함)의 메모리 공간을 회수하는 데 사용되는 Minor GC 또는 Young GC.
    • Old GC는 오래된 메모리 공간을 정리하는 것입니다.
    • Full GC는 Young 및 Old Generation을 포함하여 전체 힙 공간을 회수하는 것입니다. Java7 이전에는 영구 생성도 포함되어 있지만 Java8 이상에서는 메타 공간이 변경되므로 Java에서 가비지 수집을 제어하지 않습니다. 기본적으로 메타 공간의 메모리 공간은 사용하는 운영 체제의 메모리 공간입니다. , 그래서 공간 Metaspace의 용량은 상대적으로 충분하며, Metaspace의 공간 부족 문제는 발생하지 않습니다.Metaspace의 공간 점유가 설정된 최대 값에 도달하면 GC도 트리거되어 Dead Object를 수집하고 클래스 로더.
    • Major GC, 어떤 사람은 Old GC와 동일시하고 어떤 사람은 Full GC와 동일시할 것입니다. 우리는 이 Major GC를 언급하지 않으려고 합니다. 언급되면 상대방에게 이것이 Old GC인지 Full GC인지 묻습니다.
    • GC 및 GC 복구 알고리즘과 관련하여 작성자는 향후 블로그 게시물에 대한 자세한 소개를 작성할 것입니다.
  • HotSpot JVM은 젊은 세대를 세 부분으로 나눕니다.

    • 세 부분은 1 Eden 영역과 2 Survivor 영역(각각 from 및 to)입니다. 기본 비율은 8:1:1입니다.
    • Survivor가 없으면 Eden 영역에서 Minor GC를 수행할 때마다 살아남은 개체가 Old Generation으로 전송됩니다. Old Generation은 빠르게 채워지며, Old Generation의 메모리 공간이 일정 임계값을 초과하거나 새 세대보다 훨씬 클 경우 Full GC가 수행되며 Full GC는 Minor GC보다 훨씬 오래 소비합니다.
    • 2개의 Survivor 영역을 설정하는 가장 큰 장점은 단편화를 해결할 수 있다는 것입니다.
  • 젊은 세대가 기성세대가 되는 과정

    • 정상적인 상황에서 새로 생성된 개체는 Eden 영역에 할당됩니다.(일부 큰 개체는 특별히 처리됩니다.) 첫 번째 Minor GC 이후에
      이러한 개체가 아직 살아 있으면 Survivor 영역으로 이동합니다. 개체가 Survivor 영역의 Minor GC에서 살아남을 때마다 연령이 1
      년씩 증가하며, 일정 수준(보통 16배)이 되면 개체는 Old Generation으로 이동합니다.

6. 부록(VM 옵션 매개변수)

여기에 이미지 설명 삽입
개봉 후 내용물은 다음과 같습니다.
여기에 이미지 설명 삽입

파일 경로는 다음과 같습니다.
여기에 이미지 설명 삽입
파일 내용은 다음과 같습니다.
여기에 이미지 설명 삽입
매개변수 값은 다음과 같습니다.

  • -Xms1024m, JVM 초기 힙 메모리를 1024m으로 설정합니다. 이 값은 각 가비지 수집이 완료된 후 JVM에 의한 메모리 재할당을 피하기 위해 -Xmx와 동일하게 설정할 수 있습니다.
  • -Xmx2048m, JVM의 최대 힙 메모리를 2048m로 설정합니다.
  • -Xss512k, 각 스레드의 스택 크기를 설정합니다. JDK5.0 이후에는 각 스레드의 스택 크기가 1M이고, 이전에는 각 스레드 스택의 크기가 256K입니다. 동일한 물리적 메모리에서 이 값을 줄이면 더 많은 스레드가 생성될 수 있지만, 물론 운영 체제는 여전히 프로세스의 스레드 수에 제한이 있어 무한정 생성할 수 없습니다. 쓰레드 스택의 크기는 양날의 검이다 너무 작게 설정하면 특히 쓰레드에 재귀적이고 큰 루프가 있는 경우 스택 오버플로가 발생할 수 있으며 생성되는 스택 수에 영향을 미친다. 스레드 응용 프로그램에서는 메모리 오버플로 오류가 발생합니다.
  • -Xmn341m, 젊은 세대 크기를 341m로 설정합니다. 전체 힙의 크기가 주어지면 젊은 세대를 늘리면 이전 세대가 줄어들고 그 반대의 경우도 마찬가지입니다. 이 값은 JVM 가비지 컬렉션과 관련이 있으며 시스템 성능에 큰 영향을 미치므로 전체 힙 크기의 3/8로 구성하는 것이 공식 권장된다.
  • -XX:NewSize=341m, 젊은 세대의 초기 값을 341M으로 설정합니다.
  • -XX:MaxNewSize=341m, 젊은 세대의 최대값을 341M으로 설정합니다.
  • -XX:PermSize=512m, 영구 생성의 초기 값을 512M으로 설정하지만 java8 이상에서는 지원하지 않으므로 대신 -XX:MetaspaceSize=512m을 사용하십시오.
  • -XX:MaxPermSize=512m, 지속 생성의 최대값을 512M으로 설정합니다. 이는 java8 이상에서도 지원되지 않으며 대신 -XX:MaxMetaspaceSize=512m을 사용합니다.
  • -XX:NewRatio=2, 구세대에 대한 젊은 세대(1 Eden 및 2 Survivor 영역 포함)의 비율을 설정합니다. 젊은 세대와 구세대의 비율이 1:2임을 나타냅니다.
  • -XX:SurvivorRatio=8, 젊은 세대에서 Eden 영역과 Survivor 영역의 비율을 설정합니다. 2개의 Survivor 영역(기본적으로 젊은 세대의 JVM 힙 메모리에는 동일한 크기의 2개의 Survivor 영역이 있음)과 1개의 Eden 영역의 비율이 1:1:8, 즉 1개의 Survivor 영역이 1/10을 차지함을 나타냅니다. 전체 젊은 세대의 크기.
  • -XX:MaxTenuringThreshold=15, 자세한 내용은 JVM 시리즈의 메모리 할당 및 복구 전략에서 객체의 에이징 프로세스를 참조하십시오.
  • -XX:ReservedCodeCacheSize=240m, 컴파일된 메서드에 의해 생성된 네이티브 코드를 저장하는 데 사용되는 코드 캐시의 크기를 설정합니다.
  • 자세한 매개변수 구성 지침은 공식 문서를 참조하십시오. https://www.oracle.com/java/technologies/javase/vmoptions-jsp.html

이 기사는
CSDN
YuShiwen 에 작성된 2022.2.15에 종료되었습니다.

추천

출처blog.csdn.net/MrYushiwen/article/details/122943314