Project Loom, a new chapter in Java
Java is one of the most used programming languages in the world. Features such as Scalability, maintainability and sturdiness become a Java in really good option for big-scale applications.
In this article, I talk about scalability and the Project Loom, a disruptive change in Java 15. In march of the last year, Ron Pressler published an article about the future of concurrency in Java, called “State of Loom”. It was a awesome article, enjoyable until the last word, which in summary shows the new way to use threads with an implementation of virtual threads in the JDK 15.
What does it mean virtual thread?
The conventional implementation of threads in Java was conceived to be a wrapper of the OS threads. That’s mean which the Java Thread creates a real hardware Thread. Normally it wont be a problem, but what happen if I have different machines (with different resources) running the same app, how to choose the number of threads available?, and more important is optimal compete for resources with the OS?. The answer for these responses are simple. IT ISN’T OPTIMAL assign manually hardware resources and it doesn’t exist a simple way for choose the correct number of threads for all applications. Java in it’s latest versions used the thread pool for try to solve this concurrency problem, however, the limitation of maximum operating system thread orchestration is still there.
What alternatives exist today?
The reactive programming approach. It is an alternative that created a thread pool administrate for the application (Not the OS) and re-used them throughout the application lifecycle. The core process is to get a free thread from the pool, let it execute code, and then release the thread back to the pool. The code can not be blocking, because the thread generate a bottleneck and the application need to wait for continue the execution.
What are the key concepts of Project Loom?
According Ron Pressler, the publisher of the “State of Loom”, the keys of Loom are:
- A virtual thread is a
Thread— in code, at runtime, in the debugger and in the profiler. - A virtual thread is not a wrapper around an OS thread, but a Java entity.
- Creating a virtual thread is cheap — have millions, and don’t pool them!
- Blocking a virtual thread is cheap — be synchronous!
- No language changes are needed.
- Pluggable schedulers offer the flexibility of asynchronous programming.