https://inside.java/2021/05/10/networking-io-with-virtual-threads/

虚拟线程和普通线程的区别在于，虚拟线程由java虚拟机调度，而普通线程是操作系统线程的包装
虚拟线程 交给carrier thread 也就是执行线程（普通线程）执行，
IO阻塞 虚拟线程,执行线程不会被阻塞 ，可以去执行其他 虚拟线程
在第一个版本中，loom并不提供用户层面的schedule方法，缺省使用fork&join pool，
先交给loom，由loom来调度具体的线程 


Project Loom is intending to deliver Java VM features and APIs to support easy-to-use, high-throughput lightweight concurrency and new programming models on the Java platform. 


Threads are (currently) an expensive resource in the Java platform, 
too costly to have tied up waiting around on I/O operations to complete. 
To work around this limitation, we commonly reach for asynchronous I/O or reactive frameworks, 
since they can be used to construct code that does not result in tying up a thread in an I/O operation, 
but rather uses a callback or event notification when the I/O operation completes or is ready
 
 
Asynchronous and non-blocking APIs are more challenging to work with (than synchronous APIs), 
in part because they lead to code constructs that are not natural for a (typical) human. 
Synchronous APIs are for the most part easier to work with; 
the code is easier to write, easier to read, and easier to debug (with stack traces that make sense!)

使用异步和非阻塞api(比同步api)更具挑战性，
部分原因是它们导致的代码构造对(典型)人类来说并不自然。
大部分情况下，同步api更容易使用;代码更容易编写、阅读和调试(使用有意义的堆栈跟踪)。


 
Project Loom is to avoid having to make this choice 
it should be possible for the synchronous code to scale.
同步代码应该是可以伸缩的

同步的代码  异步的伸缩性


Virtual Threads

Virtual threads are user-mode threads scheduled by the Java virtual machine rather than the operating system. 
Virtual threads require few resources and a single Java virtual machine may support millions of virtual threads. 
Virtual threads are a great choice for executing tasks that spend much of their time blocked, often waiting for I/O operations to complete.

Platform threads (the threads that we are all familiar with in current versions of the Java platform) are typically mapped 1:1 to kernel threads scheduled by the operating system. 
Platform threads usually have a large stack and other resources that are maintained by the operating system.




Networking APIs
Asynchronous 
  AsynchronousServerSocketChannel, AsynchronousSocketChannel

Synchronous 
  java.net Socket / ServerSocket / DatagramSocket
  java.nio.channels SocketChannel / ServerSocketChannel / DatagramChannel


The synchronous networking Java APIs, when run in a virtual thread, switch the underlying native socket into non-blocking mode. 
When an I/O operation invoked from Java code does not complete immediately (the native socket returns EAGAIN - “not ready” / “would block”), 
the underlying native socket is registered with a JVM-wide event notification mechanism (a Poller), 
and the virtual thread is parked. When the underlying I/O operation is ready (an event arrives at the Poller), 
the virtual thread is unparked and the underlying socket operation is retried.





 jcmd PID JavaThread.dump threads.txt

java.base/java.util.concurrent.FutureTask.run(FutureTask.java:268)
java.base/java.util.concurrent.ThreadExecutor$TaskRunner.run(ThreadExecutor.java:385)
java.base/java.lang.VirtualThread.run(VirtualThread.java:295)
java.base/java.lang.VirtualThread$VThreadContinuation.lambda$new$0(VirtualThread.java:172)
java.base/java.lang.Continuation.enter0(Continuation.java:372)
java.base/java.lang.Continuation.enter(Continuation.java:365)
  
  
a number of frames relating to the setup of a virtual thread (“continuations” are a VM mechanism internally employed by virtual threads)

Read-Poller thread

This thread is the JVM-wide read poller. 
At its core it performs a basic event loop that monitors all of the synchronous networking read, connect, and accept operations that are not immediately ready when invoked in a virtual thread. 
When the I/O operation becomes ready, the poller will be notified and subsequently unpark the appropriate parked virtual thread. 

There is an equivalent Write-Poller, for write operations.

The above stack trace was captured when running the test program on macOS, 
which is why we see stack frames relating to the poller implementation on macOS, that is kqueue. 
On Linux the poller uses epoll, and on Windows wepoll (which provides an epoll-like API on the Ancillary Function Driver for Winsock).

The poller maintains a map of file descriptor to virtual thread. 
When a file descriptor is registered with the poller, an entry is added to the map for that file descriptor along with the registering thread as its value. 
The poller’s event loop, when woken up with an event, uses the event’s file descriptor to lookup the corresponding virtual thread and unparks it.


The default scheduler used to schedule virtual threads is the fork-join work-stealing scheduler,

The synchronous Java networking APIs have been re-implemented by JEP 353 and JEP 373 in preparation for Project Loom. 
When run in a virtual thread, I/O operations that do not complete immediately will result in the virtual thread being parked. 
The virtual thread will be unparked when I/O is “ready”. 
The implementation is using several features from the Java VM and the Core libraries to offer a scalable and efficient 
alternative that compares favorably with current asynchronous and non-blocking code constructs.