Java Reference
In-Depth Information
FindMaxTask
to finish. Only when this has happened does it call
future2.get()
. It's
possible that the second thread has already finished, in which case the value is imme‐
diately returned; but if not, execution waits for that thread to finish too. Once both
threads have finished, their results are compared and the maximum is returned.
Futures are a very convenient means of launching multiple threads to work on different
pieces of a problem, and then waiting for them all to finish before proceeding. Executors
and executor services let you assign jobs to different threads with different strategies.
This example used just two threads once each, but it's possible to use many more threads,
and to reuse threads for multiple tasks. Executors hide a lot of the nitty-gritty details of
asynchronicity as long as you can divide your job up into reasonably independent parts.
Synchronization
My shelves are overflowing with topics, including many duplicate topics, out-of-date
topics, and topics I haven't looked at for 10 years and probably never will again. Over
the years, these topics have cost me tens of thousands of dollars, maybe more, to acquire.
By contrast, two blocks down the street from my apartment, you'll find the Central
Brooklyn Public Library. Its shelves are also overflowing with topics, and over its 100
years, it's spent millions on its collection. But the difference is that its topics are shared
among all the residents of Brooklyn, and consequently the topics have very high turn‐
over. Most topics in the collection are used several times a year. Although the public
library spends a lot more money buying and storing topics than I do, the cost per page
read is much lower at the library than for my personal shelves. That's the advantage of
a shared resource.
Of course, there are disadvantages to shared resources, too. If I need a topic from the
library, I have to walk over there. I have to find the topic I'm looking for on the shelves.
I have to stand in line to check the topic out, or else I have to use it right there in the
library rather than bringing it home with me. Sometimes somebody else has checked
the topic out, and I have to fill out a form requesting that the topic be saved for me when
it's returned. And I can't write notes in the margins, highlight paragraphs, or tear pages
out to paste on my bulletin board. (Well, I can, but if I do, it significantly reduces the
usefulness of the topic for future borrowers, and if the library catches me, I may lose
my borrowing privileges.) There's a significant time and convenience penalty associated
with borrowing a topic from the library rather than purchasing my own copy, but it
does save me money and storage space.
A thread is like a borrower at a library; the thread borrows from a central pool of re‐
sources. Threads make programs more efficient by sharing memory, file handles, sock‐
ets, and other resources. As long as two threads don't want to use the same resource at
the same time, a multithreaded program is much more efficient than the multiprocess
alternative, in which each process has to keep its own copy of every resource. The
downside of a multithreaded program is that if two threads want the same resource at
