Project Loom aims to bring structured concurrency to Java, a concept that compares to “regular” concurrency like structured programming compares to GOTO-programming - let’s dip our toes into this new concept. Also: JDK 18 feature freeze, JDK migration guide, and nifty things to do with the new simple web server.
Project Loom will be a game-changer for the JVM’s concurrency model, delivering ‘reactive’ characteristics out-of-the-box without the need for complex concurrency abstractions. What project Loom tries to achieve is already available in Kotlin through Coroutines. So the nagging question is: What will be the faith of Coroutines once Loom delivers? Will they become obsolete?
In this talk, I will try to answer this question. We will first recap how Coroutines work and what they offer us, explaining the underlying concepts such as structured concurrency, suspend methods, Continuations, etc. We will then look at how project Loom tries to achieve lightweight concurrency and compare it to Coroutines using many live-coded examples. Disclaimer: Loom is not final yet, and things still can/will change, even though Loom’s central philosophy and approach have been stable so far.
At the end of the talk, you will gain a good understanding of what lays ahead of us and what the impact of Loom on Kotlin’s Coroutines will be. Will their raison d’être still hold? Or might Loom even be a blessing in disguise?
Project Loom: Modern Scalable Concurrency for the Java Platform
Concurrent applications, those serving multiple independent application actions simultaneously, are the bread and butter of Java server-side programming. The thread has been Java’s primary unit of concurrency since Java’s inception, and is a core construct around which the entire Java platform is designed, but its cost is such that it can no longer efficiently represent a domain unit of concurrency, such as the session, request or transaction. As a result, Java has seen a proliferation of libraries and frameworks that offer scalable concurrency at the cost of abandoning the thread as the unit of software concurrency and, with it, the straightforward support of Java’s troubleshooting observability tooling, such as stack dumps, debuggers and profilers. Project Loom aims to reinstate the thread as an efficient unit of concurrency by adding a lightweight implementation of threads to the Java platform, which would allow straightforward code—that’s easy to write, understand and maintain, and works in harmony with the platform and its tooling—to scale and meet the requirements of even most demanding concurrent applications.
Ron Pressler, Consulting Member of Technical Staff, Oracle
Answer - the size depends on number of CPU cores and whether the task is CPU bound or IO bound.
For CPU bound (CPU intensive) tasks, the ideal size is same as number of CPU cores.
For IO bound tasks, ideal size depends on the wait time of the IO task. More the wait time, more number of threads can be used to ensure maximum CPU utilization.
Channel
Complex concepts explained in short & simple manner. Topics include Java Concurrency, Spring Boot, Microservices, Distributed Systems etc. Feel free to ask any doubts in the comments. Also happy to take requests for new videos.
Subscribe or explore the channel - https://youtube.com/defogtech
New video added every weekend.
Popular Videos
What is an API Gateway - https://youtu.be/vHQqQBYJtLI
Executor Service - https://youtu.be/6Oo-9Can3H8
Introduction to CompletableFuture - https://youtu.be/ImtZgX1nmr8
Java Memory Model in 10 minutes - https://youtu.be/Z4hMFBvCDV4
Volatile vs Atomic - https://youtu.be/WH5UvQJizH0
What is Spring Webflux - https://youtu.be/M3jNn3HMeWg
Java Concurrency Interview question - https://youtu.be/_RSAS-gIjGo
2017-11-08 2:34:29
Subscribe to Devoxx on YouTube @ https://bit.ly/devoxx-youtube
Like Devoxx on Facebook @ https://www.facebook.com/devoxxcom
Follow Devoxx on Twitter @ https://twitter.com/devoxxJava 8 makes it relatively easy to program with parallel streams and to implement asynchronous tasks using CompletableFuture. When someone says it’s easy, cautious programmers ask “What’s the catch?” Well, of course, that’s one of the major topic we’ll address in this deep dive session. We will start with a fast introduction to parallel and asynchronous programming with Java 8 and quickly delve into the gotchas, when to use these facilities, when to avoid them, and how and where to put them to good use.
Dr. Venkat Subramaniam is an award-winning author, founder of Agile Developer, Inc., creator of agilelearner.com, and an instructional professor at the University of Houston. He has trained and mentored thousands of software developers in the US, Canada, Europe, and Asia, and is a regularly-invited speaker at several international conferences. Venkat helps his clients effectively apply and succeed with sustainable agile practices on their software projects.
Venkat is a (co)author of multiple technical books, including the 2007 Jolt Productivity award winning book Practices of an Agile Developer. You can find a list of his books at agiledeveloper.com. You can reach him by email at venkats@agiledeveloper.com or on twitter at @venkat_s
2017-10-02
Kenneth Kousen, President, Kousen IT, Inc.
The Java 8 (and 9) standard library includes multiple techniques for taking advantage of parallelism and concurrency, including parallel streams and the CompletableFuture class. Combined with the ExecutorService and other classes from java.util.concurrent, they give developers a wide range of choices for optimizing program speed. This session reviews the options and trade-offs involved.
2016-02-23
From Concurrent to Parallel
As core counts continue to increase, how we exploit hardware parallelism in practice shifts from concurrency - using more cores to handle a bigger workload - to parallelism - using more cores to solve data-intensive problems faster. This talk will explore the different goals, tools, and techniques involved between these various approaches, and how to analyze a computation for potential parallelism, with specific attention to using the parallel stream library in Java SE 8.
Brian Goetz, Oracle
Brian Goetz is the Java Language Architect at Oracle, and was specification lead for JSR 335 (Lambda Expressions for the Java Language.) He is the author of the best-selling book “Java Concurrency in Practice” and is a frequent presenter at major industry conferences.