4 ms·
With Futures and Executors/ExecutorServices I find that I rarely ever need to use raw Threads these days. Most of the thread-safety issues commonly encountered
by LgWoodenBadger 6y ago
With Futures and Executors/ExecutorServices I find that I rarely ever need to use raw Threads these days. Most of the thread-safety issues commonly encountered are eliminated with this approach as well.
- alyandon 6y agoPretty much. I can't even recall the last time I've had to touch a low level threading class in Java since the executors cover so many of the common use cases.
- Nursie 6y agoLikewise, with futures and executors I haven't had to touch threads directly for some time. They give you the tools to just say "go away and do these things", which after years of dealing directly with pthreads in C was a breath of fresh air!
- thaumasiotes 6y agoBut compare this very recent submission: https://news.ycombinator.com/item?id=24921657 https://news.ycombinator.com/item?id=24921657 which presents threads as the solution to the pain of using futures.
- jaen 6y agoSTM is not a solution to the pain of futures, STM is a "solution" to the pain of properly using locks, in particular when the concurrency is very fine-grained. A future internally is just a value or a set of waiters. Whether they are "colored" (ie. can you wait on a future in a non-future context), or based on threads or cooperative concurrency (ie. async) etc. is entirely an implementation detail, with significantly differing trade-offs. In that sense, you can really only compare future implementations with other concurrency systems.
- exabrial 6y agoI was going to comment that as well. Futures, Managed Executors, tasks, runnables, are more higher level structures that are better suited for general use. Those constructs are often implemented using threads though, so it's worth knowing what's happening one layer below the abstraction layer.
- silvestrov 6y agoyeah, calling Thread.interrupt(), join() or similar methods are often a code smell for a bad "programming 101" teacher. Executors are the way to go for almost all finite-time concurrency. New threads should normally only be used for stuff that keeps running until the process quits.
- cmckn 6y agoAbsolutely, executors offer much better (safer, more consistent) lifecycle management of a Runnable vs. a homegrown solution in my experience. The last time I extended Thread I think it was just to pull off a custom name format.
- grandinj 6y agoExcept for that pesky swallowing of exceptions, I agree
- turkogluc 6y agoI don't know why everyone is so tense in here :D I am planning to write a series of posts about concurrency (not because I am an expert but I want to improve myself by this way), including the executor framework, completable futures, locks and synchronisation. Obviously it is not possible to go into details of all in a single post. For one who knows operating system level details, and new to java I thing this is where you start, simply with Thread API. Even if you are using high-level abstraction this is these are basics to know. It is quite popular in the job interviews. And also it is quite common for people uses the Executor framework daily but does not know how to properly stop a thread, or non-daemon threads etc.
- turkogluc 6y agoI have published a new article about Executor Framework: https://turkogluc.com/java-concurrency-executor-services/ https://turkogluc.com/java-concurrency-executor-services/