Java 웹 개발 이후에는 성능 테스트와 로드 테스트가 수행될 것으로 예상됩니다.
그 단계에 이르면 많은 문제가 발생할 것이다.
나는 지금까지 발생한 문제와 조사, 해결 방법을 몇 차례로 나누어 소개하고 싶다.
우선 메모리 유출이다.
서버를 장시간 가동하고 운용하거나 부하 테스트를 실시할 때 메모리 유출이 발생할 수 있다.

복습하다

자바의 무더기는 new 영역(young 영역)과 old 영역으로 나뉜다.
생성된 객체를 new 영역에 저장하고 작은 GC에서 사용하지 않을 때 엽니다.
작은 GC를 여러 번 반복해도 열리지 않는 객체는
old 영역으로 이동하여 주 GC(전체 GC)에서 개방합니다.(주 GC는 new와perm 분야에서도 개방됩니다.)
좀 더 자세히 설명해 주세요.

new 영역은 eeden,from,to로 나뉜다.
갓 태어난 대상은 에덴에 보관되어 있다.
주 GC가 생성될 때 인용되는 (활성) 대상은
eeden 구역에서from 구역으로 이동합니다.
다음 GC에서from의 대상이 살아있다면 to영역으로 이동합니다.
엄밀히 말하면 eeden에서 to로 이동하면 다음 GC에서from과 to의 이름이 반전됩니다
from에서 to로 이동... 그리고 다음에 다시 from에서 to로 이동하는 느낌을 반전시킨다.
from to의 이동 중복 횟수 (기본 32회) 는old 구역으로 이동합니다.
대형 GC는 소형 GC에 비해 비용이 많이 든다.
GC는 전체 스레드 정지(Stop the world)가 있고, 이 기간 프로그램도 정지된다.
따라서 잦은 GC를 피하고 GC가 난방을 적당히 켜는지 주의해야 한다.
※ 병행 GC, 병행 GC 등 비용이 들지 않도록 하는 구조도 있습니다
이 근처에서 구글 좀 주세요.

jstat 명령으로 무더기의 이용 상황과 GC의 빈도를 확인합니다

GC와 무더기의 상황을 조사하는 방법은 매우 많다
우선 jstat의 간단한 조사 방법으로

목표 지정 프로세스

 jps -v | less -SN

jps 명령은 자바 프로세스를 확인하는 명령입니다.path를 통해 jdk의 bin을 실행할 수 있습니다.
- v 옵션이 나타나면 시작 옵션이 표시됩니다. 서버에 여러 인스턴스(JVM)를 엽니다.
시작할 때 이걸로 대상을 정하고 처리 ID를 정하세요.

jstat의 실행

jstat -gcutil -h3 708 1000

jstat-gcutil로 더미와 GC의 상태를 실시간으로 확인할 수 있습니다.
- h3 줄마다 머리글 표시
708은 프로세스 ID입니다. 환경에 따라 프로세스 ID를 지정하십시오.
마지막 1000은 초당 감시라는 뜻이다.
-gcold로 변경하면old 구역에 대한 더 자세한 정보를 보여 줍니다.

머리는 E열이고 메모리 사용률은 new 영역입니다.
new 영역이기 때문에 계속 증가하면 소GC가 생기고 감소한다...이렇게 반복된다.
YGC는 소규모 GC의 실시 횟수이기 때문에 계수와 동시에 new 분야의 사용률이 감소하는 것은 정상이다.
O는 old 영역이고 FGC가 주 CG인 횟수입니다.
new 영역은 전혀 떨어지지 않고 100에 붙어 있습니다. OutOfMemory Error가 발생한 경우
어디선가 동시에 대상이 생성됐기 때문에 처리를 재고해야 한다
쌓아올리는 사이즈가 필요합니까?
또한 중복 소GC, old 영역 증가, 대형 GC의 빈번한 발생
메모리 유출 혐의가 있거나 new 영역의 크기나 프로그램이 적합하지 않을 수도 있습니다.
old 영역이 계속 개방되지 않으면 OutOfMemory Error를 유발할 가능성이 높다.
이번엔 여기까지.
다음에 GC 로그에서 무더기의 개방률과 GC 시간을 볼 계획입니다.
다음은 메모리 덤프와 스레드가 체류할 때의 조사 방법 등이다.

자바 개발의 성능 개선!1Jstat을 통해 스택/GC 확인

자바 개발의 성능 개선!2GC 로그의 해석 및 Heep 설정

자바 개발의 성능 개선!3 덤프 덤프