일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- Java
- docker
- ncloud
- papago
- spring boot
- Scheduler
- Naver Cloud
- React
- 네이버클라우드
- Database
- 네이버 클라우드
- OrientalUnity
- 에프랩
- NooBLoL
- NCP
- Enum
- ngrinder
- spring
- mybatis
- DBDocs
- 회고
- AssertJ
- Naver Cloud Platform
- object storage
- Pinpoint
- F-Lab
- navercloud
- junit
- NaverCloudPlatform
- Thymeleaf
Archives
- Today
- Total
DevJong12
[작성중]Java Virtual Machine 본문
728x90
[JVM?]
- JVM이란 Java Virtual Machine으로 자바 가상머신의 약자를 줄여 부르는 용어
- 자바 어플리케이션을 클래스 로더를 통해 읽어 자바와 함께 실행
- JAVA와 OS사이의 중개자 역할로 OS에 구애받지 않고 사용이 가능하게 함.
- 메모리관리의 경우 Garbage Collection을 수행함
- 보통의 다른 하드웨어의 경우 레지스터 기반이지만 JVM의 경우에는 스택을 기반으로 작동됨
[왜 알아야 하는가?]
이건 나의 생각일뿐이다..
- 구동의 근본적인 원리를 알고 개발을 진행하게 되면 자원의 효율을 극대화가 가능하기 때문이지 않을까 싶다..
- 어느 영역을 사용하여 관리의 효율성 이나 좀더 안정적인 프로그램 실행 말이다..
[Java의 실행 단계]
- 프로그램 실행
- OS에서 프로그램 실행에 필요한(혹은 설정된) 메모리 할당
- JVM은 할당된 메모리를 여러 영역으로 나누어 관리
- Javac가 .java를 읽은 이후 .class(바이트코드)로 변환
- Class Loader를 활용해서 class파일들을 JVM으로 로딩
- 로딩된 class파일들을 Execution engine을 통해 해석
- 해석된 class파일들은 Runtime Data Area에 배치이후 수행
- 수행되는 과정에서 JVM은 Thread, Synchronization, Garbage Collector과 같은 작업을 진행
[JVM구조]
[Runtime Data Area (메모리 구조)]
- Method Area
- 모든 쓰레드가 공유하는 메모리 영역
- 클래스, 인터페이스, 메소드, 필드, Static변수등의 바이트 코드를 보관
- Heap Area
- 모든 쓰레드가 공유
- new 키워드로 생성된 객체, 배열이 생성되는 영역
- 메소드 여역에 로드된 클래스만 생성이 가능
- Garbage Collector가 참조되지 않는 메모리를 확인하고 제거하는 영역
- Stack Area
- 메소드 호출 시마다 각각의 스택프레임이 생성 됨. 그 메서드 안에서 사용되는 값들을 저장 및 호출된 메소드의 매개변수, 지역변수, 리턴값 및 연산시 일어나는 값들을 임시로 저장
- 메소드의 수행이 끝나면 프레임별로 삭제
- PC Register
- 쓰레드가 시작 될 때 생성 됨
- 생성될 때마다 생성이 되는 공간, 쓰레드마다 하나씪 존재함.
- 쓰레드가 어떤 부분을 무슨 명령으로 실행할지에 대한 기록을 하는 영역, 현재 수행중인 JVM명령의 주소를 가짐
- Native Method Stack
- 자바 외 언어로 작성된 네이티브 코드를 위한 영역
[Execution Engine(실행 엔진)]
Class Loader에 의해 Load되어 Method Area로 배치된 Class파일(바이트코드) 들을 실행하는 모듈
- Interpreter
- 바이트코드를 한 줄 씩 해석 및 실행하는 방식
- 초기 방식으로 속도가 느린 단점이 존재
- JIT(Just In Time) 컴파일러 또는 동적 번역 (Dynamic Translation)
- Interpreter방식을 보완해 나온 방법(?)으로 실제 프로그램을 실행하는 시점에 Native Code로 변환하여 실행 속도를 개선
- 모든 코드를 JIT컴파일러로 실행하지 않고 Interpreter방식을 사용하다가 일정 사용량을 이상 호출하면 JIT컴파일방식으로 명령어를 실행
- 같은 코드를 매번 해석하지 않고 실행할 때 컴파일을 진행하면서 코드를 캐싱해버림. 이후 수정이 있을 경우 수정이 있는 부분만 컴파일을 하고 나머지는 캐싱된 코드를 사용한다.
- Garbage Collector
- 더이상 참조하지 않는 객체를 정리하는 역할
- 이와 관련해서는 글을 하나 적어야 할꺼 같다...
구상도..?
차차 적어나가자...
참고자료들..
https://asfirstalways.tistory.com/158
https://steady-coding.tistory.com/305
https://m.blog.naver.com/ksw6169/221647376178
https://goodgid.github.io/Java-JVM/
728x90
'Java,Spring > Java' 카테고리의 다른 글
Java의 람다식과 변수의 관계 (0) | 2022.08.22 |
---|---|
[Tomcat] JAVA_HOME, Tomcat설정과 관련한 오류사항 정리 (0) | 2022.06.19 |
[Tomcat] JVM설정 옵션 "PermSize", "MetaspaceSize" (0) | 2022.05.30 |
JVM의 로케일 Charset과 관련한 오류사항 기록 (0) | 2022.05.20 |
String, StringBuilder, StringBuffer (0) | 2022.05.18 |
Comments