프로그램 동작 원리

• 기본적으로 소프트웨어가 작성되어 CPU에서 실행되기까지의 과정은 다음과 같다.
  • 소스파일 작성 → 컴파일러나 인터프리터가 어셈블리어로 번역 → 어셈블러가 기계어로 번역 → 목적 파일 생성 → Linking → loader module 생성 → loader → CPU execute
    1. 우리가 C나 C++ 등의 고급언어로 소스코드를 작성한다.
    2. 언어에 맞는 컴파일러(혹은 인터프리터)가 어셈블리어로 번역해준다.
    3. 어셈블리어로 번역된 파일을 어셈블러가 기계어 코드(0,1)인 목적 파일로 번역한다.
    4. 규모가 어느정도 있는 프로그램이면 한 파일에 모든 소스코드가 있지 않다. 여러 파일로 나눠져 컴파일이 된 목적 파일들을 연결해야한다. 이 과정을 Linking이라고 한다.
    5. Linker에 의해 연결한 파일을 loader module이라고 한다.
    6. loader는 loader module을 메모리에 올린다.
    7. 메모리에 올라간 loader module을 CPU가 실행한다.

그럼 JVM은 어떻게 동작하는 것일까?

JVM의 동작 원리

• Java 언어의 특징은 어떤 플랫폼, 운영체제에서도 동작하는 것이다. 앞에서 본 것처럼 목적 파일로 만들어져 바로 CPU에서 수행되는 것이 아니다.
  • 중간에 JVM을 한 번 거치게 된다.
  • 간단하게만 한번 보면 다음과 같다.
    1. 자바 소스코드를 작성한다.
    2. 자바 컴파일러가 byte code라고 불리는 .class 파일로 번역한다.
    3. JVM이 기계어 코드로 번역한다. 
       1. https://ahea.wordpress.com/2017/05/25/자바개발자가-알아야-할-jvm과-garbage-collection/

JDK 구조

• 우선 JDK의 구조부터 보자.

• 

  • JDK > JRE > JVM
  • 이런 포함관계를 갖는다.
    • JDK(java development kit)
      • 컴파일러, 디버거, JRE가 있다.
        • JRE(java runtime environment)
          • JVM과 라이브러리가 있다.
        • JVM(java virtual machine)

          • 

          • JVM 내부에는 Class Loader, Runtime Data Areas, Execution Engine 등이 있다.

Class Loader

• 클래스 로더는 바이트 코드(.class)를 받아서 필요한 클래스를 가져와 JVM의 메모리에 로드하고, 링킹하고 초기화 하는 과정을 수행한다.
• 자바는 컴파일 타임에 모든 클래스를 로드하는 방식이 아닌, 런타임에 클래스가 필요하면(참조할 때) 클래스를 로드하고 링킹하는 동적로드를 한다. - JVM에서 동적로드를 담당한다.

Class Loader 특징

이제 JVM이 어떻게 class 파일을 기계어 코드로 변환하는지 알아보자.

• 계층 구조 - JVM의 클래스 로더는 여러개가 있는데 이 클래스 로더끼리 부모-자식관계의 계층 구조를 이루고 있다.
• 위임모델 - 게층 구조를 바탕으로 클래스 로더끼리 호출을 위임한다. 클래스를 로딩할 때, 최상위 클래스로더인 부트스트랩 클래스 로더를 확인하고 이 클래스 로더에 로딩하려는 클래스가 없다면 자식 클래스 로더로 책임을 넘긴다. - 위임 모델 다이어그램
• https://d2.naver.com/helloworld/1230
  • 부트스트랩 클래스 로더
    • JVM이 처음 실행될 때 생성된다. 최상위 Object클래스와 Java api들을 로드한 - 익스텐션 클래스 로더(Extension Class Loader)
      • 기본 자바 API를 제외한 확장 클래스들을 로드한다.
        • 시스템 클래스 로더(System Class Loader)
          • 사용자가 작성한 클래스들(?), $CLASSPATH 내의 클래스들을 로드한다.
        • 사용자 정의 클래스 로더(User-Defined Class Loader)
          • 애플리케이션 사용자가 직접 코드 상에서 생성해서 사용하는 클래스 로더이다.
•  
• 가시성 제한 - 하위 클래스 로더에서는 상위 클래스로더의 클래스를 찾을 수 있다. - 반대는 안된다.
• 언로드 불가 - 클래스 로더는 클래스를 로딩만 할 수 있다. - 이미 로드된 클래스를 언로드 할 수는 없다.

클래스 로딩 과정

• 클래스 로더가 아직 로드되지 않은 클래스를 찾을 때, 로딩 → 링킹 → 초기화 과정을 거친다.
• https://d2.naver.com/helloworld/1230

1. 로딩
   • 클래스 파일을 가져와서 JVM 메모리에 로드
2. 링킹
   • 검증
     • 자바, JVM의 명세에 맞게 작성 되어 있는지 확인
   • 준비
     • 클래스가 필요로하는 메모리를 할당 (필드, 메소드 등)
   • 분석
     • 클래스의 상수 풀 내의 심볼릭 레퍼런스를 다이렉트 레퍼런스로 변경
       • 클래스 파일은 JVM이 프로그램을 실행할 때 필요한 API를 Link할 수 있도록 심볼릭 레퍼런스를 가진다. 심볼릭 레퍼런스를 런타임 시점에 메모리 상에서 실제로 존재하는 물리적인 주소로 대체하는 Linking 작업이 일어난다.
       • 심볼릭 레퍼런스는 참조하는 대상의 이름을 지칭하고, 클래스 파일이 JVM에 올라가게 되면 심볼릭 레펀선스는 실제 메모리 주소가 아닌 이름에 맞는 객체의 주소를 찾아서 연결하는 작업을 수행한다.
3. 초기화
   • 클래스 변수들을 초기화한다. → static 필드들을 설정된 값으로 초기화 한다.

Runtime Data Areas

• JVM이 OS위에서 실행되면서 할당받아 사용하는 메모리 영역이다. - 6개 영역으로 구분된다.
• https://d2.naver.com/helloworld/1230
• 쓰레드 마다 생성
  • PC Register
    • 현재 수행 중인 JVM의 명령어 주소
  • JVM Stack
    • 쓰레드가 시작될 때 생성
    • 스택 프레임을 저장하는 스택이다.
      • 메소드 스택
        • 지역변수, 매개변수, 반환 주소 등
  • Native Method Stack
    • 자바 외의 언어로 작성된 네이티브 코드를 위한 스택
• 모든 쓰레드가 공유
  • Heap
    • 인스턴스를 저장하는 공간
    • 가비지 컬렉션 대상
  • Method Area
    • JVM이 시작될 때 생성된다.
    • JVM이 읽어 들인 각각의 클래스와 인터페이스에 대한 런타임 상수 풀, 필드와 메소드 정보, static 변수, 메소드의 바이트 코드 등이 포함된다.
  • Runtime Constant Pool
    • Method Area에 포함되는 영역이다.
    • JVM에서 가장 핵심적인 역할 수행
    • 클래스와 인터페이스의 상수, 메소드, 필드에 대한 모든 레퍼런스를 담고 있는 테이블
    • 메소드나 필드를 참조할 때, 이 테이블을 통해 실제 메모리상의 주소를 찾는다.

Execution Engine

• JVM의 메모리에 올라온 바이트 코드들을 명령어 단위로 하나씩 실행한다.
• 바이트 코드(.class)를 JVM 내부에서 실행할 수 있는 형태(기계어?)로 바꾼다.
• 바꾸는 방법이 2가지가 있다
  • 인터프리터
    • 바이트 코드 명령어를 하나씩 읽고 해석해서 실행한다.
    • 하나하나의 해석은 빠르지만 전체 실행 결과는 느리다.
    • 바이트 코드는 기본적으로 인터프리터 방식으로 동작한다.
  • JIT(Just In Time)
    • 인터프리터의 단점을 보완하기 위해 도입된 JIT 컴파일러 이다.
    • 바이트 코드 전체를 컴파일하여 네이티브 코드로 변경한다.
      • 전체를 컴파일하는 과정이 인터프리터 보다 느리다.
      • 따라서 한 번만 실행되는 코드라면 컴파일 하지 않는다.
      • JIT 컴파일러를 사용하는 JVM들은 내부적으로 컴파일하려는 메소드가 얼마나 자주 실행되는지 체크하고 일정 수준 이상일 때 컴파일을 한다.

정리

1. 자바 소스코드를 작성한다.
2. JDK의 자바 컴파일러가 자바 파일을 바이트 코드로 변환한다.
3. JRE 안의 JVM의 클래스 로더가 바이트 코드를 받아서 JVM의 메모리에 올리고, 필요한 클래스들을 로딩한다.
4. 실행 엔진이 메모리 상에 있는 바이트 코드를 JVM 내부에서 실행할 수 있는 기계어 형태로 바꿔서 실행한다.

참고자료

https://yeon-kr.tistory.com/112

https://steady-snail.tistory.com/67

https://ahea.wordpress.com/2017/05/25/자바개발자가-알아야-할-jvm과-garbage-collection/

https://medium.com/@mannverma/the-secret-of-java-jdk-jre-jvm-difference-fa35201650ca

https://d2.naver.com/helloworld/1230

https://lkhlkh23.tistory.com/100

가비지 컬렉터

뭐지?

C나 C++같은 언매니지드 언어는 OS 레벨의 메모리의 직접 접근해서 메모리를 관리한다.

자바는 OS위의 JVM위에서 돌아간다. 이 JVM이 알아서 메모리 상에 필요하지 않은 데이터를 해제하여 공간을 확보해준다.

• JVM의 메모리 구조
  • 스택
    • 힙 영역에 생성된 객체를 참조하기 위한 값들이 할당된다.
    • 메서드 작업에 필요한 메모리 공간
      • 지역변수, 파라미터 등
  • 힙
    • 인스턴스가 생성된다.

예시

지역변수로 String 변수를 만들고 값을 넣으면, 참조변수는 스택에 할당되고 String 리터럴 값은 힙 영역에 할당되게 된다.

String str = "heap";

자바에서는 문자열에 어떤 다른 문자열을 더하면 원래 주소에 더해지는게 아니라, 새로운 인스턴스를 만들어 다른 주소를 참조하게 된다.

str += "123";

이처럼 더하게 되면 힙 영역에는 2개의 String 리터럴이 존재하는 것이다.

이때, 더 이상 참조하지 않는 "heap" 리터럴을 Garbage Collector가 삭제해주는 것이다.

이렇게 더 이상 참조하지 않는 객체를 Unreachable Object라고 한다.

동작

Mark → Sweep

• Mark
  • GC가 스택의 모든 변수를 스캔하면서 참조하는 오브젝트를 찾는다. 참조한 오브젝트가 참조하는 오브젝트까지 다 마킹한다.
• Sweep
  • Mark 되어있지 않은 힙의 오브젝트들을 지운다.

자바의 정석 예제 13-20

다중 쓰레드를 사용하여 가비지 컬렉터를 간단히 흉내내본 예제이다.

메모리 공간을 나누지 않았고, Unreachable Object 를 삭제하는게 아니라 시간에 따라 공간을 확보하는 식이다.

public class GarbageCollector extends Thread {
    final static int MAX_MEMORY = 1000;
    int usedMemory = 0;

    @Override
    public void run() {
        while (true) {
            try {
                Thread.sleep(10 * 1000);
            } catch (InterruptedException ie) {
                System.out.println("Awaken by interrupt()");
            }

            gc();
            System.out.println("Garbage Collected. Free Memory :"+freeMemory());
        }
    }

    public void gc() {
        usedMemory -= 300;
        if (usedMemory < 0) usedMemory = 0;
    }

    public int totalMemory() { return MAX_MEMORY; }
    public int freeMemory() { return MAX_MEMORY - usedMemory; }
}

• 최대 메모리는 1000이라고 한다.
• 10초를 sleep하고, gc()를 실행한다.
  • 사용중인 메모리를 300감소한다.

public class GarbageCollectorTest {
    public static void main(String[] args) {
        GarbageCollector gc = new GarbageCollector();
        gc.setDaemon(true);
        gc.start();

        int requiredMemory = 0;

        for (int i = 0; i < 20; i++) {
            requiredMemory = (int) (Math.random() * 10) * 20;

            if (gc.freeMemory() < requiredMemory || gc.freeMemory() < gc.totalMemory() * 0.4) {
                gc.interrupt();
                try {
                    gc.join(100);
                } catch (InterruptedException ie) { }
            }

            gc.usedMemory += requiredMemory;
            System.out.println("gc.usedMemory = " + gc.usedMemory);
        }
    }
}

• gc 객체를 데몬 쓰레드로 만들었다.
  • 데몬 쓰레드는 일반 쓰레드가 모두 종료되면 자동으로 종료되는 쓰레드이다.
    • 데몬 쓰레드로 지정하지 않으면, for문을 다 돌고 메인 쓰레드가 종료되어도 gc는 다른 쓰레드에서 계속 실행되게 될 것이다.
• 랜덤 값을 메모리 사용량으로 계속 넣는다.
• 여유공간이 필요공간보다 적거나, 여유공간이 40% 미만이면 잠자고 있는 가비지 컬렉터를 깨운다.
  • 깨우지 않더라도 10초마다 작동한다.
• 깨우는 부분을 보면 interrupt() 외에도 join() 메소드가 있다.
  • gc를 깨우고 가비지 컬렉션이 시작되기 전에 메인 메소드에서 또 추가를 할 수 있으므로 기다릴 시간을 주는 것이다.
  • join()에 지정된 시간동안 작업을 수행하고 호출장소로 돌아온다.
    • 지정된 시간동안은 메인 쓰레드가 수행되지 않는 것이다.

gc.usedMemory = 20
gc.usedMemory = 20
gc.usedMemory = 20
gc.usedMemory = 60
gc.usedMemory = 100
gc.usedMemory = 120
gc.usedMemory = 160
gc.usedMemory = 200
gc.usedMemory = 380
gc.usedMemory = 520
gc.usedMemory = 520
gc.usedMemory = 640
Awaken by interrupt()
Garbage Collected. Free Memory :660
gc.usedMemory = 340
gc.usedMemory = 360
gc.usedMemory = 460
gc.usedMemory = 520
gc.usedMemory = 640
Awaken by interrupt()
Garbage Collected. Free Memory :660
gc.usedMemory = 420
gc.usedMemory = 580
gc.usedMemory = 580

Process finished with exit code 0

• 실행 결과는 이런식으로 나온다.

참고

https://yaboong.github.io/java/2018/06/09/java-garbage-collection/

일반적으로 웹에서 사용하는 프로토콜인 HTTP는 stateless 프로토콜이다. 따라서 로그인 상태를 유지하기 위해서는 추가적인 방법이 필요하다.

로그인 상태를 유지하기 위한 방법 중 하나인 쿠키 세션 방식을 알아보자.

그 외에, 사용자 분석과 광고, 개인화 등을 위해 쓰이기도 한다.

쿠키

클라이언트가 로그인 인증(Authorization)을 서버로 보내면, 서버는 쿠키가 있는지 확인하고, 없다면 쿠키를 생성해서 응답 요청에 담아서 보낸다.

응답 요청에서 쿠키를 받은 클라이언트는 브라우저의 쿠키 저장소에 쿠키를 저장하고, 다음 요청 때마다 쿠키를 같이 보낸다.

그러면 서버는 요청 헤더에 있는 쿠키를 보고 서버 내부에 있는 쿠키와 일치하는게 있으면 해당 사용자로 인식하게 된다. 

쿠키는 4KB이하의 String으로 이루어져 있다.

쿠키의 적용을 받는 경로, 유효기간 등을 정할 수 있다.

세션

로그인 상태 유지를 쿠키로 하고, 사용자의 아이디와 비밀번호를 쿠키에 저장한다면, 쿠키가 유출될 경우 다른 사용자가 쿠키를 사용해서 로그인 할 수도 있다.

세션은 이런 쿠키의 취약점을 보완할 수 있다.

세션은 비밀번호 같은 인증정보를 서버쪽에 저장한다. 그리고 클라이언트에게 주는 쿠키에는 사용자를 식별할 수 있는 세션 ID를 저장한다.

클라이언트는 세션 ID를 요청에 같이 보내고, 서버는 세션 ID를 통해 인증된 사용자인지 판별한다.

서버 쪽에는 유저 이름, 만료기한 등의 정보가 저장된다.

세션은 쿠키를 사용하지만, 사용자의 정보를 브라우저가 아닌 서버에서 관리한다. 클라이언트 쪽에서 관리하는 것 보다는 보안상 유리하지만, 세션을 사용자 수만큼 생성하므로, 사용자가 많아질수록 서버에 부하가 크다.

세션은 timeout이 되거나, 로그아웃하면 서버에서 삭제된다.

HTTP가 뭐냐?

• TCP/IP 네트워크 아키텍처에서 어플리케이션 계층에서 사용하는 프로토콜이다.
• 자신이 보내고자 하는 데이터에 시작라인과 헤더 등을 붙여 목적지에 전송한다.
• 예를들어 구글에 http를 검색하면 GET메소드, path= /search?q=http , version의 start-line과 헤더정보가 붙어 서버로 전송된다.
• GET메소드는 보통 조회를 위해 사용하고, 포함되는 데이터는 없이 요청만 한다.
• http프로토콜은 이런식이 된다. 
• HTTP의 특징 중 하나로는 Stateless라는 것이다.

Stateless

• 서버가 클라이언트의 상태를 보존하지 않는다는 뜻이다. 클라이언트의 상태라는 것은 로그인 여부나 해당 클라이언트로부터 이전에 들어온 요청 등을 말한다.
• 
• stateless 특징때문에 클라이언트는 한번에 요청에 모든 정보를 담아서 보내야 한다.
• 
• 상태를 보존하지 않기 때문에 HTTP만으로는 로그인을 유지할 수 없다. 쿠키/세션 등을 이용해서 로그인을 유지하는 방법이 있다.
• 이렇게만 들으면 왜 stateless로 만든거지, 별로 아닌가 라고 생각할 수도 있다.
• 하지만 stateless 특성은 큰 이점을 가진다.
  • 상태를 유지한다면, 이전에 데이터를 보냈던 해당 서버하고만 통신을 할 수 있다.
    • 같은 서비스를 제공하더라도 물리적인 서버가 여러대 존재할 수 있다.
    
    • 일련의 요청 중에 서버에 장애가 난다면 서버에 처음부터 다시 보내야한다.
  • 상태를 유지하지 않는다면, 특정 서버와 클라이언트에 의존하지 않고 통신할 수 있다.
    • 서버 부하에 따라 다른 서버로 요청을 보내 유동적으로 처리 할 수 있다.
    • 트래픽이 많아졌을 때, 응답 서버를 늘리기가 쉽다는 장점이 있다.
• 단점은 요청 데이터의 크기가 크다. 따라서 매 요청마다 요청과 응답에 많은 네트워크 자원을 사용하게 된다.