스프링 스터디 3주차 회고

1주차때 배운 개념과 연결지으며 공부해야겠다고 생각했다

 

예를 들어

쓰레드를 생성할 때 어떤 오버헤드가 발생하나요? 라는 질문에 대한 모범적인 답은

 

컨텍스트 스위칭으로 인한 오버헤드가 발생하고

쓰레드의 어떤 영역을 차지하는지 (힙 스택) 등

힙을 차지하긱 때문에 GC발생 확률이 올라가고 언젠간 GC의 대상이 됨

 

자바에서 스레드는 OS의 스레드와 1대1 매핑이 된다.

결국 OS에서 관리할 스레드도 늘어나게 되는 것이다.

 

그래서 미리 정해진 갯수만큼 생성해서 재활용 하는 것이다.

 

이처럼 명확하게 설명할 줄 알아야 한다.

 

특히 JVM에 대해서 구체적으로 알아야 한다.

 

 

이해가 부족하다고 생각한 개념 :

 

블락킹 큐 -> 이게 무엇이고 언제쓰지?

풀이 넘치면 어떤 예외가 발생하는지

디비용 스레드 풀

블락킹 개념

LockSupport.park() 개념

CoundDown Latch

JVM의 구성 요소. 자바 코드가 실행될 때 어떤 일이 발생하는지 설명할 수 있어야 한다.

jstack으로 synchronized 일반메서드, 스태틱 메서드로 직접 만들어서 락을 발생 시켜 두개가 어떻게 다르게 락이 걸리는지 테스트 해보기

코드만보고도 한줄한줄 메모리에 어떻게 올라가는지 공부해보자

컨텍스트 스위칭이 일어날 때 스레드와 프로세스에서 어떤 일이 발생하는지

쓰레드가 생성될 때 내부적으로 어떤 일이 일어나는지

 

새롭게 얻은 지식

톰캣은 리퀘스트 스레드 풀을 세팅할 수 있음.

 디폴트 세팅으로 쓰지만, 트래픽이 많으면 최적화가 필요함

스레드풀에 몇개의 스레드를 잡아야 하고 큐의 크기를 어떻게 하는게 좋을까요? 라는 질문에 대한 답은

 

그 회사 서비스의 피크 트래픽 -> 큐의 크기를 정함 -> 큐가 넘치치 않게 적당한 크기를 잡는다

일하고 있는 스레드와 놀고 있는 스레드의 수를 비교해서 큐의 크기를 조절한다.

정답은 없다. 서비스 마다 다르다 라는게 정답,

 

블락킹이 걸릴 때 디비 네트워크 리퀘스트 스레드에서 블록킹이 걸리면 디폴트 200개가 들어오면 디비에 들어가면 디비용 쓰레드 풀을 만들어서 리퀘스트 스레드 풀에서 디비용 스레드풀로 옮겨가게 하여 최적화 한다.

 

 

스레드 덤프를 뜰 때는 락을 기다리는 보통 Blocked를 기다린다.

waiting을 아무도 풀어주지 않거나 블락부터 찾기 시작한다.

 

스레드 풀의 이름을 잘 지어야 스레드 덤프 분석을 빠르게 할 수 있다.

 

모든 스레드가 waiting, blocked 상태이면 장애를 의심해봐야 한다.

코드의 문제인지 스레드 풀의 사이즈 문제인지 파악해야 한다.

 

메모리 GC를 엄청돌아서 1초에 두번씩, GC가 돌아도 해제가 안되면 메모리 누수가 있는 경우이다.

 

이런거 말고, 리퀘스트가 오는 순간, CPU가 널널하고 메모리가 널널하면 무조건 스레드 덤프를 떠서 확인해보는것이 좋다

 

 

static은 클래스에 락을 거는 것이고

non-static은 오브젝트에 걸린다.

 

스태틱은 락 객체를 만들어 순서를 보장할 수 있다.