daehwan2yo / dig-up-kotlin Goto Github PK

View Code? Open in Web Editor NEW

1.0 1.0 0.0 30 KB

Kotlin 100.00%

dig-up-kotlin's Introduction

반갑습니다 🙌

Without haste, but without rest

dig-up-kotlin's People

Contributors

Stargazers

Watchers

dig-up-kotlin's Issues

Map & MutableMap

Map

A collection that holds pairs of objects (keys and values) and supports efficiently retrieving the value corresponding to each key as read-only.
Map keys are unique; the map holds only one value for each key.

MutableMap

A modifiable collection that hold pairs of objects (keys and values) and supports efficiently retrieving the value corresponding to each key.

idempotent 주의

Why kotlin lateinit Can't be used with primitive types?

reference
https://www.baeldung.com/kotlin/lateinit-primitive-types
https://www.baeldung.com/kotlin/lazy-initialization

kotlin 이 nullability 하게 primitive type 을 다루는 방식을 고민해야한다.
lateinit properties 에 대해 고민해야한다.

lazy initialization pattern in Java

lazy 의 목적은 불필요한 객체 생성을 방지하는 것이다.
- 필요 할 때 초기화하여 객체를 사용한다.
Singleton

lazy initialization in kotlin

kotlin 은 lateinit keyword 를 통해 compiler 를 속이고 생성자 대신 클래스 본문에서 null 이 아닌 필드를 초기화 할 수 있도록한다.

Lazy Properties

lazy 적용시 Thread 의 접근을 제어한다.

LazyThreadSafetyMode

SYNCHRONIZED
- default
- 한 Thread 의 접근만 허용하며, 모든 thread 에서 접근해도 같은 값 (singleton) 을 보장한다.
  - 여러 Thread 로 부터 안전하게 하나의 값만 전달한다.
  - thread lock 에 대한 비용이 발생한다.
PUBLICATION
NONE

Kotlin 에서 lateinit 은 nullable 해야한다.

lateinit 을 통해 초기화가됐는지 여부를 null 통해 판단한다.

그러나 kotlin 에서 primitive type 들이 compile 될때 java 의 primitive 한 값들로 되므로, 이때 Int 의 경우 int 로 컴파일 되어진다.
- java 의 int 의 경우에는 nullable 하지 않다.
? 를 사용해 nullable 하게 만들면 해결되지 않을까?
- nullable 한 필드 초기화는 lateinit 의 목적에서 벗어난다.

위와 같은 이유들로, kotlin 에서는 primitive type 들에 대해 lateinit 을 적용할 수 없다.

kotlin contract

reference

Contract

컴파일러에게 명시해주는 방법

일반적으로 우리가 if 분기와 같은 처리를 통해 코드상 특정 값들이 검증된 값임을 알 수 있으나, 컴파일러는 모른다.
- 따라서 컴파일러에게 알려주어 런타임에 검증과 같은 분기들이 수행되는 것이 아닌, 컴파일 수행으로도 알 수 있게하여 개발 중에 에러체킹을 가능하도록 한다.

kotlin inner class and nested class

Test 를 구성하고 있는데, @ Nested 가 반영되지 않고 테스트가 한번에 수행되지 않아서 inner 와 nested 마다 테스트가 실행되는
방식을 이해할 필요가 있다.
-> 한번에 되지 않은 이유는 Java 에서 자연스럽게 inner class 로 명시해서 활용한 부분이 kotlin 에서는 nested 로 적용되어
@ Nested 가 적용되지 않았다. -> inner 를 명시해주면 해결된다.

https://kotlinlang.org/docs/nested-classes.html

둘의 차이는 무엇일까?
java 에서의 inner class 와 무슨 차이일까?

Nested 와 Inner 를 사용하는 이유

객체의 생명주기와 연관이 있다.

Nested 같은 경우는 감싸고 있는 클래스의 생성과 연관이(참조가) 없다.
- 즉, 객체의 생성과 소멸이 감싸는 클래스의 생성과 연관이 없어 쓰레기 객체를 만들지 않게 된다.
- 따라서 Nested Class 에서는 상위 클래스의 field 에 대한 접근이 불가능하다.
  - java 의 경우 static 하게 만들어 접근을 해주어야한다.
- Nested 는 독립적인 객체로써 생성주기가 관리되어진다.
Inner class 같은 경우는 감싸고 있는 클래스 (상위 클래스)의 생성과 연관이 (참조가) 있다.
- 따라서 inner class 만 null 로 만든다고 해서 상위 객체가 GC 의 대상이 되지 않는다.
  - 쓰레기 객체로 남아 메모리 낭비가 발생할 수 있다.

Nested

중첩 클래스

nest interfaces in classes
nest classes in interface
nest interfaces in interface
nest classes in classes

class Outer {
  private cal var : Int = 1

  // 별도의 맴버 명시 없이 사용하면 nested 의 역할을 수행하는 클래스
  class Nested {
     fun foo() = 2
   }
}


val demo = Outer.Nested().foo() // ==2

Inner

내부 클래스, members if its outer class

class Outer {
  private val bar: Int = 1
  inner class Inner {
      fun foo() = bar
   }
}


val demo = Outer().Inner().foo // ==1

Suspension work in kotlin

reference

Suspending a coroutine means stopping it in the middle.

when suspended, return a continuation, can use it to continue from the point where we stopped.

Thread 와는 다른 개념이다.

Suspending function 은 coroutine 을 일시 중단 시킬 수 있다.
- must be called from a coroutine. (or another suspending function)

coroutine with kotlin

Maintaining a blocked thread is always costly, while maintaining a suspended coroutine is almost free.

coroutines should never block threads, only suspend them.

Why we use runBlocking() for test coroutines?

일반적으로 코루틴은 쓰레드를 block 하지 않지만, main thread 가 너무 일찍 종료되어 코루틴을 동작하지 못해 blocking 이 필요한 경우가 있다. 이런 경우 runBlocking builder 를 통해 코루틴 동작을 위해 thread 를 block 시킨다.

Kotlin Generic

Memory Management

https://kt.academy/article/ek-object-references

Java nio to Kotlin

NIO

Java New Input & Output

from JDK 4 to implement high-speed I/O operations
alternative to the standard I/O APIs

using java nio

Non-blocking I/O Operations
- reads data whichever is ready
- thread can ask a channel to read data from a buffer and thread can go for other work
  - if I/O finished, thread can continue again from the previous point
Buffer oriented approach

Channel
: I/O abstraction

a bit like stream used for communicating with the outside world
read data from a buffer or write from a buffer
Channel allows java NIO non-blocking operations

Selectors
: an Object which monitors multiple channels for the events

handling multiple channels which are using single thread

기존 java io package 와 차이점

C 와 같은 언어와 달리 JVM 위에서 동작하는 언어로, 직접 메모리를 관리하거나, os 수준의 system call 을 사용할 수 없기에, Kernel buffer (read()) 로 읽어들여온 데이터를 Process (JVM) 으로 이동시켜주는 추가적인 작업 (Context Switching 발생) 이 일어난다.
- thread block 발생
  java io package 는 stream oriented, java nio pacakge 는 buffer oriented
java io 는 blocked working
java nio 는 channel 에 read 요청을 보내고 channel 이 read 하며 buffer 를 채우는 동시에 thread 는 다른 작업을 수행가능하도록한다.
- thread 가 read() 혹은 write() 를 수행을 channel 에 요청하여 thread 가 block 되어지지 않는다.