phantasmicmeans 기술 블로그

Hello World intellj에 코틀린 프로젝트 생성 및 Hello world는 아래 문서로 https://kotlinlang.org/docs/tutorials/jvm-get-started.html 1. Variables Kotlin은 불변성을 강제하지 않는다. var / val을 사용하여 이를 컨트롤 하면 된다. val: immutable var: mutable val a: String = "initial" // immutable var b: Int = 1 // mutable 또한 Kotlin은 타입 추론을 잘한다. 변수 선언시 타입을 포함하지 않아도 대입 값을 보고 타입 추론한다. var c = 3 // compiler infers the type Int var d = "ABC" // compi..

일반적인 flow는 Publisher -> Data -> Subscriber이다. 그러나 Publisher -> [Data1] -> Operator -> [Data2] -> Operator2 -> [Data3] -> Subscriber 처럼 Operator를 활용해 Subcriber에 도달하는 Data를 컨트롤 할 수 있다. 쉽게 말해 Operator는 Data를 가공한다. JAVA8의 Stream 관련 메소드와 비슷한 의미를 가진다고 보면 된다 아래 코드는 3가지 operator를 거쳐 logSubscriber에게 데이터가 전달되는 과정을 나타낸다. 기본 개념은 아래와 같다. 대리 Subscriber를 사용하여 subscriber를 연결한다. 초기 Publisher에서 정의한 Subscription을 ..

흐름 제어 푸시모델만 사용하는것으로는 기술적 한계가 있다. 메시지 기반 통신의 본질은 요청에 응답하는 것이다. Producer가 Subscriber의 처리 능력을 무시하면 시스템에 악영향을 끼칠 수 있기 때문에 매우 까다롭다. 느린 프로듀서와 빠른 컨슈머 컨슈머가 매우 빠르게 동작하는 상황에서 프로듀서가 느리게 동작한다고 가정하자. 이러한 상황은 컨슈머의 능력을 프로듀서가 믿지 못하기에 발생할 수 있다. 상황에 따라 컨슈머의 처리 능력이 동적으로 변할 수도 있다. 가장 쉽게는 프로듀서 수를 늘려서 컨슈머에게 부담을 증가시킬 수 있고 그렇지만.. 결론적으로 이러한 문제를 해결하기 위해 필요한 것은 실제적 요구이다. 순수 푸시모델은 이러한 메트릭을 제공할 수 없으므로 동적으로 시스템의 처리량을 증가시키는 것..

Publisher Rective Stream에서 정의하는 Publisher는 sequential한 element들을 제공하는 provider이고, Subscriber의 요구에 따라 publish 한다. 앞서 살펴보았던 Observable과 동등한 의미로 보면 된다. Observable은 registerObserver(Observer observer)로 subscriber를 등록했다면, Publisher는 subcribe(Subscriber

앞선 글에서 Observer pattern + Iterator 패턴(이벤트의 끝, 그리고 Error) == Reactive Stream이라고 정리했다. 이와 더불어 토비의 리액티브 스트림 첫 강의에서 나온 Iterable Observable (Duality) 에 대해 짚고 넘어가자 Duality Iterable Observable [Iterable] [Observable] [Pull] [Push] [값을 끌어온다는 의미] [값을 가져가라는 의미] [iterator.next()] [notifyObservers(arg)] Iterable, Observable Pull, Push 먼저 Iterable과 Observable의 Pull-Push 차이를 보자. Iterable을 구현한 클래스들은 for-each s..

Iterator 반복자 패턴 RxJava(ReactiveX)는 Observer pattern, Iterator pattern 및 함수형 프로그래밍의 조합으로 사용된다. Observer pattern은 무한한 데이터 스트림에 매력적이다. 그러나 데이터 스트림의 끝 을 알리는 기능이 없고, 에러 전파 메커니즘 또한 포함하고 있지 않다. 또한 consumer가 준비되기 전 producer가 이벤트를 생성하는 것은 그다지 좋은 상황도 아니다. 동기식의 경우 이런 때를 대비해서 Iterator 패턴이 존재한다. public interface Iterator { T next(); boolean hasNext(); } 위 Iterator interface는 하나씩 항목을 검사하기 위한 next() method와 다음..

관찰자 패턴은 관찰자라고 불리는 자손의 리스트를 가지고 있는 주체(Subject) 를 필요로한다. 주체는 일반적으로 자신의 메서드 중 하나(e.g. notify)를 호출해 관찰자에게 상태 변경을 알리게 된다. GoF 에서의 옵저버 패턴 설명 객체 사이에 일대 다의 의존 관계를 정의해두어, 어떤 객체의 상태가 변할 때 그 객체의 의존성을 가진 다른 객체들이 변화를 통지받고 자동으로 갱신될 수 있게 만든다. 이 패턴은 이벤트 처리 기반 시스템에 필수적 e.g. MVC 패턴, 거의 모든 UI 라이브러리가 내부적으로 이 패턴 사용 Subject - Observer 는 1:N 관계를 이룰 수 있음. Subject |- Observer |- Observer |- Observer |- Observer 일반적인 옵저버..

CompletableFuture를 활용해 작업을 하다 우연히 스레드명을 로깅하게 되었고 이는 default로 ForkAndJoinPool()을 사용하는 것을 알았다. ForkAndJoinPool()은 Java 7에서 도입되었으며 보통의 ExecutorService와 비슷하나 차이점을 가진다. 사실 이름만 봐도 어느정도 감이 올것이다. ForKAndJoinPool은 2가지 recursive한 스텝을 가진다. 1. Fork 첫 번째 작업은 "split itself" 이다. 자신을 더 작은 subTask로 나눈다. 이후 subTask는 parallel or concurrent하게 실행된다. 위 그럼처럼 Task를 SubTask로 fork하여 분리한다. subTask는 parallel하게 실행되거나, cpu c..

JVM 내의 Reference는 GC와 관련해 이해하는 것이 좋다. JVM Heap Memory Reference JVM의 Garbage Collector가 Garbage Collecting을 행하는 기준을 설명한다. 일반적으로 Garbage Collector는 Stack내의 원소들을 훑으며 각 원소가 Heap Memory내의 어떠한 객체를 참조하고 있는지 체크하고 기록한다. 이를 Marking 이라 한다. 일반적인 경우 Stack내의 원소를 "객체 참조의 Root Set"이라 한다. 물론 이것만 있는 것은 아니다. Heap의 객체들에 대한 참조는 다음과 같다. 1. 힙 내의 다른 객체에 의한 참조 2. Java Method 실행시 사용되는 지역변수 및 파라미터에 의한 참조 3. JNI에 의해 생성된 객..