이에 대한 질문은 이미 다루었지만 (예 : https://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads ), 만족스러운 답을 얻지 못한 것 같습니다.
질문은 : JVM이 더 이상 녹색 스레드를 지원하지 않는 이유는 무엇입니까?
코드 스타일 Java FAQ 에 다음과 같이 나와 있습니다.
녹색 스레드는 모든 코드가 단일 운영 체제 스레드에서 실행되는 JVM (Java Virtual Machine)의 작동 모드를 나타냅니다.
다음은 java.sun.com 에 있습니다.
단점은 녹색 스레드를 사용한다는 것은 Linux의 시스템 스레드가 활용되지 않음을 의미하므로 추가 CPU가 추가 될 때 Java 가상 머신을 확장 할 수 없다는 것입니다.
JVM이 코어 수와 동일한 시스템 프로세스 풀을 보유한 다음 그 위에 녹색 스레드를 실행할 수있는 것 같습니다. 이것은 자주 차단되는 스레드 수가 매우 많을 때 큰 이점을 제공 할 수 있습니다 (주로 현재 JVM이 스레드 수를 제한하기 때문입니다).
생각?
댓글
- 나에게 질문은 왜 녹색 스레드입니까? 다중 프로세스를 통해 JVM 수준에서 에뮬레이션하여 다중 스레딩을 다시 도입하는 이유는 무엇입니까? ' 프로그래머가 스레드 생성에 더 관대하게 할 수 있도록하는 것 외에는 아무런 이득이없는 것처럼 보이는 많은 고통과 오버 헤드가 발생합니다 (나는 ' ' 이점).
- 확장 가능한 동시 프로그래밍 모델을 갖는 것이 '입니다. 현재 Java에서는 확장 성을 원할 경우 자신의 스레드 풀을 사용하여 NIO로 전환합니다. 적어도 '이 이해합니다.
- < akka.io > rts 경량 스레드는 또한 필요가 있다고 생각하게 만듭니다. 실제로 여기에서 좋은 토론을 찾았습니다. < stackoverflow.com/questions/7458782/ … >
- @delnan 네이티브 스레드에 대한 컨텍스트 전환 비용이 발생하기 때문입니다. 녹색 스레드는 컨텍스트 전환 및 프로세스 간 동기화에 대한 오버 헤드가 훨씬 적습니다. 또한 녹색 스레드의 양은 사실상 무제한이며 (VM 프로세스에 너무 많은 스트레스없이 수십만 개가 될 수 있음) 네이티브 스레드의 양은 OS 및 메모리 오버 헤드에 의해 제한됩니다.
- It JVM이 네이티브 스레드를 직접 지원하기까지는 오랜 시간이 걸렸습니다. 그때까지는 녹색 스레드가 중간 솔루션이었습니다.
답변
JVM이 녹색 스레드를 버리고 네이티브 스레드. 이것은 두 가지 간단한 이유 때문입니다. 녹색 스레드는 솔직히 쓰레기였으며 Sun에서 제한된 개발자 노력으로 멀티 코어 프로세서를 지원해야했습니다.
이것은 부끄러운 일이었습니다. 녹색 스레드는 훨씬 더 나은 추상화, 동시성이 걸림돌이 아닌 유용한 도구가 될 수 있습니다. 그러나 녹색 스레드는 몇 가지 장애물을 극복 할 수 없다면 소용이 없습니다.
-
사용 가능한 모든 CPU 코어를 사용해야합니다.
-
컨텍스트 전환은 저렴해야합니다.
-
I / O는 관련된 모든 스레드를 차단할 수 있지만 다른 스레드는 아닙니다 다른 모든 스레드는 차단할 수 없습니다. , 일부 초기 구현의 경우였습니다.
나는 종종 Java에서 멀티 스레딩이 왜 그렇게 어려운지 궁금해했지만 이제는 더 명확 해지고 있습니다. 네이티브 스레드로의 전환은 다음과 같습니다.
-
모든 CPU 코어 사용에 능숙
-
진정한 동시, 독립적 I / O 제공 등
-
컨텍스트 전환 속도가 느림 (최상의 녹색 스레드 구현과 비교)
-
무섭게 메모리에 탐욕 스럽기 때문에 사용 가능한 최대 수를 제한합니다.
-
실제 세계를 표현하기위한 모든 기반에 대한 추상화가 좋지 않습니다. 물론 동시성이 매우 높습니다.
요즘에는 많은 프로그래머의 시간이 이제 비 차단 I / O, 미래 등을 코딩하는 데 사용됩니다. 더 나은 수준의 추상화가 없다는 것은 큰 수치입니다.
For 비교하면 Erlang 외에도 새로운 Go 언어는 엄청난 동시성을 잘 수행합니다. 그들 모두의 할아버지는 아직 진행중인 연구 프로젝트 인 Occam 으로 남아 있습니다.
댓글
- 당신이 게시 한 이후로 우리가 얼마나 멀리 갔는지 : O
- 아아, Rust는 더 나은 동시성 추상화를 포기한 또 다른 언어입니다. 그들도 협동 쓰레드에서 네이티브 쓰레드로 이동하기로 결정했습니다.
- @ Rick-777 Rust는 그렇게하기에는 너무 낮은 수준입니다.
답변
여러 스레드를 위조하는 단일 프로세스에는 많은 문제가 있습니다. 그 중 하나는 모든 가짜 스레드가 페이지 오류로 인해 중단된다는 것입니다.
당신이 제안하는 대안 인 프로세스 풀에는 몇 가지 장점과 단점이 있습니다. 가장 큰 장점 인 “스레드”의 격리는 여기에서 많은 것을 얻지 못할 것입니다. 큰 단점, 구현의 극심한 어려움 및 덜 효율적인 동기화는 여기에서 거래 킬러입니다.
그러나 저는 스레드 풀처럼 사용할 수있는 프로세스 풀 (하지만 더 많은 격리를 포함)이 유용한 일부 애플리케이션 (Java가 아님)이 있다는 데 동의합니다. 스레드는 거의 모든 것을 공유합니다. 프로세스를 사용하면 다음 작업을 수행 할 수 있습니다. 구체적으로 무엇을 공유할지 선택하세요. 제가 아는 한 아무도이를 구현하려고 노력하지 않았습니다.
댓글
- Occam이이를 제공한다고 주장합니다. ' 80 년대에는 중요한 언어 였지만 개발 자금이 부족하여 결과적으로 연구 틈새 시장이되었습니다.하지만 동시성에 대한 아이디어는 당시처럼 견고하고 아직 개선되지 않았습니다.
- " 다중 스레드 " al 인 경우 golang (" M : N " 유형 스케줄링)이면 이론적으로 하나의 녹색 스레드 만 페이지 폴트로 차단됩니다. 다른 스레드는 " 느슨 함을 선택하세요 " (다른 녹색 스레드) … softwareengineering.stackexchange.com/questions/222642/…
답변
일반적인 Java 코드에는 전혀 이점이 없습니다. Java는 Erlang이 아니며 Java 프로그래머는 Erlang 프로그래머와 같은 사고 방식이 아닙니다. 이 언어는 이러한 방식으로 사용되도록 의도 된 것이 아닙니다.
진정한 경량 프로세스를 원한다면 Erlang을 사용하고 메시지를 통해 통신하는 수천 개의 스레드를 만드십시오. Java에서는 “뮤텍스 및 세마포어와 공통 메모리를 공유하는 수십 개의 스레드가 있습니다. 이는 다른 문제 세트를 위해 설계된 다른 프로그래밍 모델 일뿐입니다.
코멘트
- 하지만 명확히하기 위해 Erlang에서는 유용한 접근 방식입니다. Java 사고 방식의 문제를 무시하면 실제로 도움이 될 수 있습니까?
- @redjamjar, 가능성이 낮습니다. Java에서 유용하기 위해 언어 자체는 그러한 용도에 적합하지 않습니다. 그리고 그 주된 (유일한) 장점 인 바로 사용할 수있는 라이브러리의 방대한 본문이 적합하지 않습니다. ' 그런 외계 프로그래밍 접근 방식에 잘 맞습니다.
- 그 모델을 원한다면 Erlang을 사용하십시오. 훨씬 더 쉬울 것입니다.
- Java! = JVM, 그냥 🙂
- @Bane, 이러한 " 장점 "은 ' 비교할 것이 없습니다