12/27 반복자의 상태와 컬렉션의 상태가 다를때 발생하는 에러

 

반복자의 상태와 컬랙션의 상태가 동기화 되지않기 때문에 에러가 발생한다.

(for-each문은 내부적으로 iterator로 해석됨.)

iterator를 명시적으로사용하고 remove를 호출하면 이러한 문제를 해결할 수 있지...만!!

이때문에 removeIf라는 메서드가 등장하였다!

12/26 무한스트림 OOM을 주의하기 ㅋㅋㅋ

 

무한스트림을 생성한후 limit하는 걸 까먹었더니 생전처음 oom을 만났다... 웃기다 ㅋㅋ

12/26 비동기 논블로킹 서블릿 스레드

 1. 서블릿 스레드가 요청(작업)을 받는다(서블릿 스레드 풀에서.)  

2. 비지니스 로직을 처리한다 -> 이부분을 워커 스레드에게 위임하고 return

3. 워커스레드가 돌아오면, 서블릿스레드 풀에 그 작업이 다른 스레드에게 할당. 유저에게 response를 준다. 

-

논블로킹이 아니었을 경우

->2번에서 블로킹이 일어나므로. 해당 스레드 대기큐로 들어가서 쿨쿨 잔다.

-> 메모리 사용량은 올라가는데 cpu는 놀고있는 비효율적인 상황발생.

-

비동기 블로킹 / 비동기 논블로킹을 잘 구분해야!!

12/25 람다 혹은 익명클래스 외부변수 접근 제약

 Variable used in lambda expression should be final or effectively final

- 람다, 익명클래스는 다른 스레드에서 실행될 수 있다.

- 만약에 람다,익명클래스가 외부변수에 자유롭게 접근할수있다고 해보자.

- 그 람다/익명클래스를 만든 스택은 이미 사라지고 free변수도 사라졌는데, 람다/익명클래스는 그 지역변수를 계속해서 참조하려고 하는 에러가 발생한다.

- 따라서 , final 혹은 effectively final 인 외부변수에만 람다/익명객체는 접근할 수 있다.

-원래는 final키워드를 명시적으로 붙이는것이 맞으나 1.7부터는 컴파일러가 알아서 붙여준다고 한다.

-그러므로 - 결론적으로 :

- 람다/익명객체는 외부변수에 자유롭게 접근 가능하다.

- 그러나 지역변수의 경우 스택에 위치하므로, effectively final한 특성을 가지고 있어야 한다.

- 위 코드의 경우 effectively final 해야한다는 특성을 어겼으므로 컴파일러가 final키워드를 붙여서 처리해줄수없다. 따라서 에러가 난다.

12/24 스레드 무한정 생성해보기

 유투브가 버벅대고 다른 프로그램이 열리지않게 됨 ㅋㅋㅋㅋ 재밌다 ㅋㅋㅋ

스레드 무한생성하는 main두개 돌린결과..

12/24 리액티브 모델

 1. 메시지 드리븐 / 이벤트 드리븐

message driven : 하나의 목적지를 향한다.

event driven : 해당 이벤트가 등록된 컴포넌트를 향한다.

-> 이벤트 드리븐 모델에서는 특정 메시지와 특정 어플리케이션이 결합되지 않도록 하여, 유연성을 유지하고자 한다. 

2. 리액티브 프로그래밍 

- 반응성 : 유저에게 밀리세컨드 단위로, 좀더 빠르게 응답할수있어야 한다. 

- 회복성 : 장애가 일어났을때 회복할수있는 방법이 있어야 한다. 작업을 다른 어플리케이션에게 위임한다던지 등등. 

- 탄력성 : 부하가 가해졌을때 크기를 확장하는 등 탄력적으로 대응할 수 있어야 한다. 

- 이벤트 드리븐 : 발행 - 구독 방식으로 대응할 수 있어야 한다. 

3. 이벤트 드리븐 방식으로 인하여, 어떠한 하나의 어플리케이션에 장애가 일어나더라도 그 장애는 다른 어플리케이션으로 전파되지 않는다. 직접적으로 메시지로 연결되어있지 않기 때문이다. (kafka나. messageMQ를 쓰는데는 다 이유가 있던것이다...) 어떤 어플리케이션에 장애가 일어날 경우, 그 어플리케이션은 회복될때까지 격리된다. 
- 만약에 메시지 드리븐 방식이었다면, 해당 메시지가 특정 어플리케이션을 직접적으로 가리키므로, 장애가 일어나면 장애가 계속 연쇄적으로 전파되었을 것이다. 

- 하나의 공통된 DB에 의존하기 보다 카프카와 같은 발행-구독 기반 모델을 사용하여, 서로간의 결합도를 낮추고 - 좀더 장애에 탄력적인 서비스를 제공할 수 있게 된다.

12/24 블로킹과 논블로킹

 

일반적인 메서드의 경우 delay가 되는동안 - 해당 스레드는 아무작업을 하지않고 룰루랄랄라 하면서 네트워크/IO/DB에서 데이터 읽어오기 등등... 의 결과가 돌아오는 것을 기다린다. 이 동안 블로킹이되며 해당 스레드가 맡고있는 태스크가 있기 때문에 다른 작업이 할당되지 않는다. 

그러나 논블로킹으로 할경우 , 작업을 다른 스레드에게 맡기고 - 호출된 스레드는 바로 반환된다. 이렇게 함으로써 반환된 스레드는 다른 작업을 하고 있을 수 있다. CPU 연산작업도 하면서 네트워킹 기능도 수행하고 이렇게 효율적으로 스레드 자원을 사용할 수 있는것이다.

이러한 작업을 CompletableFuture 혹은 Future 를 통하여 구현할수있다. 

단 Future.get() 메서드를 불렀을때 작업이 완료되지않은 상태이면 그동안 블로킹이 되는데, 그렇기 때문에 타임아웃을 설정하는 등 고려해볼 수 있다.