멘토링 학습 사항 정리 (9.2, 추후 정리)

멘토링 학습 사항 정리 (9.2, 추후 정리)

1. annotation processor

컴파일 타임에 annotation을 확인해서 사용자가 지정한 기능을 수행하는, 컴파일러에 동봉된 훅.

input으로 자바 소스 코드(.java)나 컴파일된 바이트코드 (.class 파일)을 받아서 output으로 컴파일 에러/경고, 변경된 .java/.class 파일을 내놓는다. 즉, 어노테이션이 붙은 코드를 참조해서, 새로운 코드를 내놓는다.

참고

https://heewon26.tistory.com/213

https://catsbi.oopy.io/78cee801-bb9c-44af-ad1f-dffc5a541101

https://kkambi.tistory.com/84

https://andole98.github.io/java/java-annotation-process/#

https://hamait.tistory.com/314

2. blocking io / non blocking io / Concurrent

io 작업은 기본적으로 사용자 애플리케이션에서 직접 수행될 수는 없고, 시스템 콜로 커널 측에서 수행해야 한다.

즉, 시스템 콜을 호출하여 커널 레벨 스레드를 하나 만들고, 커널 레벨 스레드 측에서 io 작업을 진행하게 된다.

1. blocking i/o

시스템 콜을 불러 커널 레벨 스레드에서 i/o 작업을 진행하는 동안, 사용자 애플리케이션에서는 커널 레벨 스레드로부터 결과값이 오기 전까지 어떠한 작업도 하지 못한다. 즉, 결과값이 오기 전까지 주구장창 기다려야 한다. 이렇게 커널로부터 결과값을 받기 전까지 사용자 애플리케이션은 어떠한 작업도 하지 않고 기다리는 상태를 block이라고 한다.

sync blocking i/o

2. non blocking io

blocking 상태에서는, cpu가 어떠한 일도 처리 하지 않고 놀게 된다(idle). 차라리, 커널에 io작업을 맡기고 자신은 다른 일을 처리하다가, 커널에게 io작업이 완료되었는지 물어보는 게 더 효율적일 것이다. 이러한 모델이 non blocking io이다.

non blocking io에서는, 유저 어플리케이션에서 Read()를 실행하면 커널 쪽에서 io작업을 시작하고, 곧바로 EAGIN/EWOULDBLOCK 에러 코드를 돌려 준다. 즉, "io 작업이 완료되지 않았으니, 이따가 다시 불러주세요~"하고 응답하는 것이다. 그래서 사용자 어플리케이션 측에서는 조건문을 돌며 대기하다가(busy wait) 다시 시스템 콜을 하고, 커널 측에선 작업이 완료되지 않았다면 곧바로 에러 메시지를, 완료되었다면 데이터를 돌려준다.

이 모델도 비효율적인 것은 마찬가지이다. 왜냐하면, 커널의 io작업이 끝날 때까지 계속 시스템 콜을 해서 context switch를 해가며 busy wait 상태에 놓이기 때문이다.

3. println synchronized + blocking io

synchronized : 캐시된 공유 변수가, 레지스터에서 램으로 써지기 전까지 다른 쓰레드들은 대기하라. (blocked)

println 함수는 synchronized 내에, write() 메서드를 실행함.

4. Atomic (AtomicBoolean, AtomicInteger)

5. 쓰레드 장점

6. 버퍼 사용하는 이유

7. ulimit

from http://sanghoonly.tistory.com/78 by ccl(A) rewrite - 2021-09-13 03:01:12