JDK 21의 신기능 Virtual Thread 알아보기 (안정수 James) 

개인적인 생각 인걸 감안하고 봐주시면 감사 하겠습니다 요청을 처리 할수 있는 만큼 보낸다 논블락에 백프레셔 전략이랑 비슷 할거 같아요 요청을 chunk 단위로 보내던 타임을 걸어서라도 느리게 보내야 할거 같아요 또 rdb는 scale up 하는데 한계가 있으니 중간에 큐를 추가해서 큐에 메시지 발행 후 처리 하던지 별도 no-sql로 처리 해야 할거 같기도 해요 근데 가상 쓰레드 처리 하는데 처리시 마다 디비 컨넥션 맺는 방식은 그냥 보여주기 위함이고 실제로는 저런식으로는 쓰면 안될거 같아요 비슷하게 서드파티 서비스 호출할때도 한방에 보내면 처리 가능한 서비스도 많지는 않을거 같단 생각도 들어서 각 서비스 특성별 고려해서 사용 하는게 좋을거 같아요 어쨌든 쓰레드별로 디비 컨넥션 맺어야 한다면 안쓰는게 맞아 보입니다

결국 디비 커넥션엔 한계가 있으니 말씀처럼 레플리카로 처리가 가능한 상황이면 스케일아웃 해주는 방법이 유효할 것 같네요.

스레드 당 하나의 커낵션을 맺는게 문제 상황이면 요청을 일정 기준에 따라 모았다가 한번에 처리할 때 커넥션을 맺으면 될 것같다는 생각이 드는데 쉽지 않아보이네요

문제는 그래도 개느림..

성능말고도 중요한 요구사항과 변수가 많으니까요.

1. JDK 21기준으로 node.js에 비해 I/O intensive한 작업에서 유의미한 차이가 나지 않고, CPU intensive한 작업에서는 오히려 유의미한 강점을 갖습니다. 2. Mavne, Gradle의 존재로 3-Party library 관리하기가 아주 용이합니다. NPM의 버전관리는 아주 원시적이죠. 3. 시장에 숙련자가 많아 구인하기가 아주 용이합니다. 4. 언어의 문법이 제한적이고, 타입 시스템이 아주 강력해 오히려 협업환경에서 좋습니다. 부가설명을 해보자면, - 그렇게 JS 좋다는 사람들도 막상 개발자 수십, 수백명 이상의 협업환경을 겪으면 JS 좋다는 얘기를 절대 하지 못하죠. MS가 괜히 TS를 만든게 아닙니다. - 10명의 JS 개발자가 있다면 10인 10색의 코드스타일이 나오는데 반해 10명의 Java개발자가 개발을 해봐야 어차피 Java의 제한적인 문법때문에 상당히 일관적인 코드가 나옵니다. 이는 대규모 협업환경에서 개발자가 아무리 많아져도 코드의 일관성이 어느정도 보장된다는 의미와 같습니다. 5. 언어, 생태계의 하위호환성에 대한 집착이 병에 가까운 수준이라 이게 오히려 실무환경에서 유지보수성을 최대치로 끌어올립니다. 3-Party library의 마이너 버전 하나가 변경되었다고 프로젝트가 실행되지 않는 JS 생태계와 비교하면 사실 비교하는게 미안한 수준이긴 합니다. 6. Spring Boot 하나면 대부분의 엔터프라이즈 요구사항이 커버됩니다. Spring Boot의 버전만 맞추면 모든 하위 라이브러리의 버전이 통일되는 BOM의 존재도 아주 강력하죠.

Java 는 대규모 협업환경이 될수록 다른 언어들에 비해 선형적인 강점이 생깁니다. JS는 언어나 생태계가 server side에서 쓰기에는 낙제점을 줄수밖에 없다고 보고요. 1~3명 정도의 소수 개발자가 협업하는 환경이라면 별 문제 없이 사용할수는 있겠네요. 시간이 지나도 1~3명일지는 잘 모르겠지만요

@@김삿갓-z4q 설명 감사합니다.

@@김삿갓-z4q cpu-intensive, 개발자/3rdparty공급망 외에는 장점없고, 나머지 말씀하신 부분은 여러언어들 다 비슷할듯해요.

Golang의 고루틴을 가져온게 아니고, CS에 Continuation라는 개념을 프로그래밍 언어로 구현한겁니다. Golang의 고루틴, Kotlin의 코루틴, JS의 async-await, Python의 Generator 등 모두 동일한 개념이에요. 자바의 경우 Continuation를 먼저 구현하고 이 결과물로 Fiber를 구현한겁니다.