Good talk, unless you're building a small-to-medium web site: in that case this video is just a technically inaccurate marketing. My JVM can launch 12k threads (after a minor reconfiguration of systemd limits I was easily able to create 30k threads in 3 seconds). That is more than enough for small-to-medium. Yes threads take up stack memory, yes there's context switching (although there is none for threads blocked by IO and thus lying dormant, and intra-process context switching is quite cheap). The most important part is that fibers introduce dark magic which backfires (byte-code manipulation (Quasar) or compiler converting code into state machine (Kotlin)); callbacks introduce callback hell; AKKA - when used for loading data via request-response messages - will grind your code into a 1000-lines message() method - good luck figuring out what's going on in that kind of app. But it's funny to watch the "event" community to strive to write synchronous thread-like code with yet another insane Scala construct. Threads (when done right, e.g. using 1 master thread to hold/synchronize the state (just as the node.js event loop), and n slave threads to do background blocking work (ExecutorService)) are extremely easy to understand - no lock knowledge is needed, no memory model knowledge is needed. This is a perfect fit for an app with moderate user number (10000 concurrent users, and that's quite a portal). Saying "walk away from threads" holds the same fallacy as "Walk away from SQL" - it is true, but only for large apps asynchronous in nature, dealing with massive loads! Do the measurements, prove that you have enough users that you're willing to throw away the simplicity of sequential programming threads offer, and only then move towards whatever else there is, being aware that the complexity will increase tenfold. It will be hard to debug, hard to reason about, bugs hard to spot, this is not a silver bullet at all! Don't be too eager to sacrifice simplicity.
>> Threads (when done right, e.g. using 1 master thread to hold/synchronize the state (just as the node.js event loop), and n slave threads to do background blocking work (ExecutorService)) That's actually not the "bare threads" jvm model that speaker tags obsolete. You're describing javascript/nodejs/vertx/awt/swing/javafx single threaded event loop model, not a very popular thing in java. Bare threads model is what about "Java concurrency in practice" is about - total hell of concurrent threads accessing shared state, with all the fruits of it like deadlocks, data races, visibility problems, lock contention, spurious wakeups taking ~20% of cycles on a heavy load and so on. That is what speaker is trying to "walk away from".
One of the best presentation in terms of overview and ease of explaination..
Very very good explaination
Thanks!
Good talk, unless you're building a small-to-medium web site: in that case this video is just a technically inaccurate marketing. My JVM can launch 12k threads (after a minor reconfiguration of systemd limits I was easily able to create 30k threads in 3 seconds). That is more than enough for small-to-medium.
Yes threads take up stack memory, yes there's context switching (although there is none for threads blocked by IO and thus lying dormant, and intra-process context switching is quite cheap). The most important part is that fibers introduce dark magic which backfires (byte-code manipulation (Quasar) or compiler converting code into state machine (Kotlin)); callbacks introduce callback hell; AKKA - when used for loading data via request-response messages - will grind your code into a 1000-lines message() method - good luck figuring out what's going on in that kind of app. But it's funny to watch the "event" community to strive to write synchronous thread-like code with yet another insane Scala construct.
Threads (when done right, e.g. using 1 master thread to hold/synchronize the state (just as the node.js event loop), and n slave threads to do background blocking work (ExecutorService)) are extremely easy to understand - no lock knowledge is needed, no memory model knowledge is needed. This is a perfect fit for an app with moderate user number (10000 concurrent users, and that's quite a portal).
Saying "walk away from threads" holds the same fallacy as "Walk away from SQL" - it is true, but only for large apps asynchronous in nature, dealing with massive loads! Do the measurements, prove that you have enough users that you're willing to throw away the simplicity of sequential programming threads offer, and only then move towards whatever else there is, being aware that the complexity will increase tenfold. It will be hard to debug, hard to reason about, bugs hard to spot, this is not a silver bullet at all!
Don't be too eager to sacrifice simplicity.
>> Threads (when done right, e.g. using 1 master thread to hold/synchronize the state (just as the node.js event loop), and n slave threads to do background blocking work (ExecutorService))
That's actually not the "bare threads" jvm model that speaker tags obsolete. You're describing javascript/nodejs/vertx/awt/swing/javafx single threaded event loop model, not a very popular thing in java.
Bare threads model is what about "Java concurrency in practice" is about - total hell of concurrent threads accessing shared state, with all the fruits of it like deadlocks, data races, visibility problems, lock contention, spurious wakeups taking ~20% of cycles on a heavy load and so on. That is what speaker is trying to "walk away from".
Give goroutines a try you would know what is simplicity.
it would be cool if you gave a talk on that
5 years on never heard of these fibers. And project loom is still in development
what is exactly a fiber at hardware level?
Everything that is not thread uses one of the thread from thread pool for executing task.
Thread pool is pre-reallocated group of threads.
Btw the slides are available at www.slideshare.net/lutzh/jvm-concurrency-on-devoxx-at-nov-12-2015
Why all the sample code blocks are blank and with, omg bring some color linting please