1주차 pr (#4)

ch02/5uhwann.md

@@ -0,0 +1,45 @@
+# Ch2. JVM 이야기
+
+## 인터프리팅과 클래스로딩
+- JVM은 스택 기반 해석 머신
+  - 인터프리터의 기본 로직은 마지막에 실행된 명령어를 순서대로 처리하는 **while 루프 안의 switch문**
+- 자바 어플리케이션의 진입점인 `main()` 메서드에 프로그램의 제어권을 넘기기 위해서는 클래스 로딩이 필요하다.
+  - **자바 클래스 로딩 매커니즘**
+    1. 부트스트랩 클래스가 자바 런타임 코어 클래스 로드(java.lang, java.util, java.io ...)
+    2. 확장 클래스 로더 생성
+    3. 어플리케이션 클래스 로더 생성
+  - 한 시스템에서 클래스는 풀 클래스명(패키지명 포함)과 자신을 로드한 클래스로더, 두 가지 정보로 식별됨
+
+## 바이트 코드 실행
+- javac(자바 컴파일러)의 자바 소스 코드 컴파일. 소스코드 -> .class 파일
+  - **클래스 파일 구조**
+    1. Magic Number
+    2. Version
+    3. Constant Pool
+    4. Access Plug
+    5. this Class
+    6. SuperClass
+    7. Interface
+    8. field
+    9. method
+    10. attribute
+
+## 핫스팟 입문
+### JIT 컴파일
+- 자바 프로그램이 성능을 최대로 내기 위해 바이트 코드를 네이티브 코드로 컴파일 기법
+- 어플리케이션을 모니터링 하면서 가장 자주 실행되는 코드 파트를 발견해 JIT 컴파일 수행
+- 컴파일러가 해석 단계에서 수집한 추적 정보를 바탕으로 최적화를 결정
+- 자바 소스코드와 실제로 JIT컴파일 후 실행되는 코드는 원본 코드와 전혀 다른 모습
+
+## JVM 메모리 관리
+- Garbage Collection을 이용해 힙 메모리를 자동관리
+- **자바 성능 최적화의 중심 주제**
+
+## JVM 모니터링과 툴링
+- JMX
+  - JVM 기반 어플리케이션 제어, 모니터링 툴
+- 자바 에이전트
+  - 자바 언어로 작성된 툴 컴포넌트
+  - java.lang.instrument 인터페이스를 통해 메서드 바이트코드 조작
+- VisualVM
+  - 자바 어플리케이션 시각화 툴

ch03/5uhwann.md

@@ -0,0 +1,41 @@
+# Ch3. 하드웨어와 운영체제
+
+## 메모리
+### CPU 캐시
+- CPU에 있는 메모리 영역
+- 레지스터보다는 느리지만 메인 메모리보다는 빠름
+- 자주 엑세스하는 메모리 위치는 CPU가 메인 메모리를 재참조 하지 않게 사본을 CPU 캐시에 보관
+- 각 코어별 L1, L2 캐시, 모든 코어가 공유하는 클로벌 L3 캐시를 두어 최적화
+
+## 운영체제
+- 여러 실행 프로세스가 공유하는 리소스 엑세스를 관장(주로 메모리, CPU)
+
+### 스케줄러
+- 프로세스 스케줄러는 CPU 엑세스를 통제, 실행 큐 이용
+- OS는 특성상 CPU에서 코드가 실행되지 않는 시간을 유발, 따라서 실제 관측한 프로세스에서 나온 통계치는 다른 프로세스의 동작에도 영향을 받음 -> 측정 결과에 노이즈 생성
+- 스케줄러의 움직임을 확인하는 가장 쉬운 방법은 OS 스케줄링 과정에서 발생시킨 오버헤드를 관측하는 것
+
+### 시간 문제
+- OS는 저마다 타이밍이 다르게 작동한다.
+
+### 컨텍스트 교환
+- OS 스케줄러가 현재 실행 중인 스레드/태스크를 없애고 대기 중인 다른 스레드/태스크로 대체하는 프로세스
+- 스레드 실행 명령과 스택 상태를 교체하는 모든일에 연관
+- 유저 모드에서 커널 모드로의 교환 시 모든 OS의 모든 캐시가 무효화 되어 시스템 콜에 대한 비용이 가려짐
+  - 리눅스는 가상 동적 공유 객체(vDSO)를 통해 시스템 콜의 속도를 높여 커널 모드로 컨텍스트 교환을 하지 않음
+
+## 기본 감지 전략
+### CPU 사용률
+- CPU 사용률은 어플리케이션 성능을 나타내는 핵심 지표
+- CPU 효율성 상승은 성능 향상의 지름길
+- 어플리케이션 성능 분석 시에는 시스템에 충분한 부하를 가해 사용률을 간능한 한 100%에 가까워야 한다.
+- `vmstat`
+  - proc: 실행 가능(r) 블로킹된(b) 프로세스 개수 나타냄
+  - memory: 스왑 메모리(swpd), 미사용 메모리(free), 버퍼 사용 메모리(buff), 캐시 메모리(cache)
+  - cpu: 유저 시간(us), 커널 시간(sy), 유휴 시간(id), 대기 시간(wa), 도둑맞은 시간(st 가상 머신에 할애)에 대한 사용율 표기
+  - swap, io,, system
+- 성능 측정 결과 CPU 사용률이 100%에 근접하지 않았다면 그 원인을 따져봐야 한다.
+
+## 가비지 수집
+- GC는 유저 공간의 CPU 사이클을 소비하되 커널 공간의 사용률에는 영향을 미치지 않기 때문에, JVM 프로세스가 유저 공간에서 CPU를 100%에 가깝게 사용한다면, GC를 의심해야 한다.
+- GC 로깅은 데이터의 원천으로서의 가치가 높기 때문에 JVM 프로세스는 예외없이 GC로그를 남겨야 한다.