Download Torrent Pdf Java Concurrency In Practice Goetz
Takako Dito
While my perspective may be biased, my current intention for updating the book would be almost strictly additive, covering fork-join, parallel decomposition, and the new parallel bulk data operations coming in Java SE 8.
Yes, it's still valid in my mind. There isn't big change in this area from 6 to 7. Fork-join is a new feature, which is very suitable for divide-and-conquer type of problems. But all the existing stuff inside the book, such as synchronization, volatile, servlet, are still very valid.
I bought this book in 2013. I had very serious doubts that it would be current and useful given that this edition was published so long ago. The technology world moves quickly, and software technology even faster. Even so, this book is foundational. The concepts and practices that are discussed are more underpinnings for good software design and engineering than updates on the latest and greatest API's. This book has been indispensable, and I am glad that I got it before I had decided to write even a single line of concurrent code. It's probably saved me countless hours.
Yes definitely it's still valid, but I will recommend in addition or as an introduction The Well-Grounded Java Developer a well written book with a chapter on modern Java concurrency techniques and nicely done examples.
If you are going to start your project using Java 8 you might want to consider fresh books and tutorials as well because of new stuff appeared in Java 8 like streams,lambdas and new atomics - that changes development methods a little bit.
Well, the book looks promising when I read certain preview chapters online. It gives enough insight on Java and general concurrency aspects. One can keep this book as a handy outfit when designing and implementing both naive and sophisticated concurrency applications.
For compute-intensive tasks, an Ncpu-processor system usually achieves
optimum utilization with a thread pool of Ncpu+1 threads. (Even
compute-intensive threads occasionally take a page fault or pause for
some other reason, so an "extra" runnable thread prevents CPU cycles
from going unused when this happens.) For tasks that also include I/O
or other blocking operations, you want a larger pool, since not all of
the threads will be schedulable at all times.
You should use pmap for compute-intensive tasks. For blocking I/O I'd use core.async with thread macro or pipeline-blocking (go or pipeline can be used instead of pmap), agent with send-off or j.u.c. thread pool directly.
As Sean said pmap is a quick-and-dirty mechanism which you should generally avoid.
People often recommend using java Executors framework instead (via interop).
There's also an alternative implementation of pmap (and other concurrency constructs in where you can specify your own thread pool.