왜 녹색 스레드?

나는 이것에 대한 질문이 이미 다루어 져 있음을 알고 있지만 (예 : https://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads ) 만족스러운 답변을 얻지 못한 것 같습니다. .

문제는 JVM이 더 이상 녹색 스레드를 지원하지 않는 이유 입니다.

그것은에서이 작업을 말한다 코드 스타일 자바 자주 묻는 질문 :

녹색 스레드는 모든 코드가 단일 운영 체제 스레드에서 실행되는 JVM (Java Virtual Machine)의 작동 모드를 나타냅니다.

그리고 이것은 java.sun.com에 있습니다 :

단점은 녹색 스레드를 사용한다는 것은 Linux의 시스템 스레드를 이용하지 않으므로 추가 CPU를 추가 할 때 Java 가상 머신을 확장 할 수 없다는 의미입니다.

JVM에는 코어 수와 동일한 시스템 프로세스 풀이있을 수 있으며 그 위에 녹색 스레드를 실행할 수있는 것 같습니다. 이것은 종종 차단하는 많은 수의 스레드가있을 때 (대부분 현재 JVM이 스레드 수를 제한하기 때문에) 큰 이점을 제공 할 수 있습니다.

생각?

녹색 스레드를 포기하고 기본 스레드로 이동하는 JVM을 기억합니다. 이것은 두 가지 간단한 이유 때문입니다. 녹색 스레드는 솔직히 쓰레기였으며 Sun에서 제공하는 개발자의 노력으로 멀티 코어 프로세서를 지원해야했습니다.

부끄러운 녹색 스레드는 훨씬 더 나은 추상화를 제공하므로 동시성이 걸림돌이 아닌 유용한 도구가 될 수 있습니다. 그러나 여러 장애물을 극복 할 수없는 경우 녹색 스레드는 사용되지 않습니다.

• 사용 가능한 모든 CPU 코어를 사용해야합니다

• 컨텍스트 전환은 저렴해야합니다

• I / O는 다른 스레드가 아닌 다른 스레드가 아닌 다른 스레드를 차단할 수 있습니다 . 이는 일부 초기 구현의 경우였습니다.

Java에서 멀티 스레딩이 왜 그렇게 어려운지 궁금해졌지만 이제는 점점 더 명확 해지고 있습니다. 궁극적으로 네이티브 스레드로의 전환과 관련이 있습니다.

• 모든 CPU 코어 사용에 능숙

• 독립적 인 I / O 등을 제공하여 진정한 동시성

• 컨텍스트 전환시 속도가 느림 (최상의 녹색 스레드 구현과 비교)

• 기억에 몹시 욕심이 많으므로 사용 가능한 최대 수를 제한합니다.

• 현실 세계를 표현하기위한 어떤 근거에 대한 열악한 추상화는 물론 매우 동시 적이다.

오늘날 많은 프로그래머 시간이 비 차단 I / O, 선물 등을 코딩하는 데 사용되고 있습니다.

비교를 위해 Erlang 외에도 새로운 Go 언어는 동시성이 뛰어납니다. 그들의 할아버지는 여전히 진행중인 연구 프로젝트 인 Occam으로 남아 있습니다 .

여러 스레드를 속이는 단일 프로세스에는 많은 문제가 있습니다. 그중 하나는 모든 가짜 스레드가 모든 페이지 결함에서 중단된다는 것입니다.

프로세스 풀에서 제안하는 대안에는 몇 가지 장점과 단점이 있습니다. '스레드'의 가장 큰 장점은 실제로 여기에 많은 도움이되지 않습니다. 큰 단점, 구현의 극도의 어려움 및 덜 효율적인 동기화는 여기서 중요한 문제입니다.

그러나 스레드 풀처럼 사용할 수있는 프로세스 풀 (더 격리 됨)이 좋은 응용 프로그램 (Java가 아님)이 있음에 동의합니다. 스레드는 거의 모든 것을 공유합니다. 프로세스를 통해 공유 할 대상을 구체적으로 선택할 수 있습니다. 내 지식으로는 아무도 그것을 구현하려는 노력을 기울이지 않았습니다.

평균적인 Java 코드에는 전혀 이점이 없습니다. Java는 Erlang이 아니며 Java 프로그래머는 Erlang 프로그래머와 같은 사고 방식이 아닙니다. 이 언어는 결코 이런 식으로 사용되지 않았습니다.

진정한 가벼운 프로세스를 원한다면 Erlang을 사용하고 메시지를 통해 통신하는 수천 개의 스레드를 만드십시오. Java에는 뮤텍스 및 세마포어와 공통 메모리를 공유하는 수십 개의 스레드가 있습니다. 다른 문제에 맞게 설계된 다른 프로그래밍 모델 일뿐입니다.