[#84][B팀] 프로그램의 동작을 스레드 스케줄러에 기대지 말라

[#84][B팀] 프로그램의 동작을 스레드 스케줄러에 기대지 말라

11장/84_프로그램의_동작을_스레드_스케줄러에_기대지_말라_이주현.md

@@ -0,0 +1,104 @@
+## Item 84 프로그램의 동작을 스레드 스케줄러에 기대지 말라
+  - 여러 스레드가 실행 중이면 운영체제의 스레드 스케줄러가 어떤 스레드를 얼마나 오래 실행할지 정한다.
+  - 정상적인 운영체제라면 이 작업을 공정하게 수행하지만 구체적인 스케줄링 정책은 운영체제마다 다를 수 있다.
+  - **정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램이라면 다른 플랫폼에 이식하기 어렵다.**
+  - 견고하고 빠릿하고 이식성 좋은 프로그램을 작성하는 가장 좋은 방법은 **실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 하는 것이다.**
+  - 실행 가능한 스레드 수를 적게 유지하는 주요 기법은 각 스레드가 무언가 유용한 작업을 완료한 후에는 다음 일거리가 생길 때까지 대기하도록 하는 것이다.
+  - **스레드는 당장 처리해야 할 작업이 없다면 실행돼서는 안 된다.**
+  - 스레드는 절대 바쁜 대기(busy waiting) 상태가 되면 안 된다.
+  - 공유 객체의 상태가 바뀔 때까지 쉬지않고 검사해서는 안 된다는 뜻이다.
+
+
+<br>
+
+### 바쁜 대기(Busy Waiting)
+
+```html
+바쁜 대기(영어: busy waiting 또는 spinning)란 어떠한 특정 공유자원에 대하여 두 개 이상의 프로세스나 스레드가 
+그 이용 권한을 획득하고자 하는 동기화 상황에서 그 권한 획득을 위한 과정에서 일어나는 현상이다. 
+대부분의 경우에 스핀락(Spin-lock)과 이것을 동일하게 생각하지만, 엄밀히 말하자면 스핀락이 바쁜 대기 개념을 이용한 것이다.
+
+https://ko.wikipedia.org/wiki/%EB%B0%94%EC%81%9C_%EB%8C%80%EA%B8%B0
+
+
+바쁜 대기(Busy Waiting)
+원하는 자원을 얻기 위해 기다리는 것이 아니라 권한을 얻을 때까지 확인하는 것
+ => 권한 획득을 위해 많은 CPU를 낭비한다는 단점이 존재함
+```
+
+https://simsimjae.tistory.com/289
+
+<br>
+
+### Thread.yield
+  - 다른 쓰레드에게 작업(실행)을 양보하고 실행 대기 상태가 된다.
+
+```java
+class MyThread extends Thread {
+
+    @Override
+    public void run() {
+        for (int i = 0; i < 5; i++)
+            System.out.println(Thread.currentThread().getName() + " in control");
+    }
+}
+
+public class Main {
+    public static void main(String[] args) {
+        MyThread t = new MyThread();
+        t.start();
+
+        for (int i = 0; i < 5; i++) {
+            // Control passes to child thread
+            Thread.yield();
+
+            // After execution of child Thread
+            // main thread takes over
+            System.out.println(Thread.currentThread().getName() + " in control");
+        }
+    }
+}
+
+
+main in control
+Thread-0 in control
+Thread-0 in control
+Thread-0 in control
+Thread-0 in control
+Thread-0 in control
+main in control
+main in control
+main in control
+main in control
+
+
+main in control
+main in control
+Thread-0 in control
+Thread-0 in control
+Thread-0 in control
+main in control
+Thread-0 in control
+Thread-0 in control
+main in control
+main in control
+
+```
+
+![image](https://user-images.githubusercontent.com/50076031/113724561-6fcd9a80-972d-11eb-825e-6c890c573e78.png)
+
+https://www.geeksforgeeks.org/java-concurrency-yield-sleep-and-join-methods/
+
+  - 특정 스레드가 다른 스레드들과 비교해 CPU 시간을 충분히 얻지 못해서 간신히 돌아가는 프로그램을 보더라도 **Thread.yield를 써서 문제를 고쳐보려는 유혹을 떨쳐내자.**
+  - 증상이 어느정도 호전될 수 있으나 이식성은 그렇지 않을 것이다.
+  - Thread.yield는 테스트할 수단도 없다.
+  - 차라리 애플리케이션 구조를 바꿔 동시에 실행 가능한 스레드 수가 적어지도록 조치해주자.
+
+<br>
+
+### 핵심 정리
+  - 프로그램의 동작을 스레드 스케줄러에 기대지 말자.
+  - 견고성과 이식성을 모두 해치는 행위다.
+  - 같은 이유로, Thread.yield와 스레드 우선순위에 의존해서도 안 된다.
+  - 이 기능들은 스레드 스케줄러에 제공하는 힌트일 뿐이다.
+  - 스레드 우선순위는 이미 잘 동작하는 프로그램의 서비스 품질을 높이기 위해 드물게 쓰일 수는 있지만, 간신히 동작하는 프로그램을 '고치는 용도'로 사용해서는 ✏절대✏ 안 된다.