The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update
| Version |
Location |
Description |
Submitted by |
Date submitted |
| Printed |
Page 109
"Reference Objects" box |
The changes you made to the softref/weakref discussion in the 1/01 reprint only partially fix the error here. Lines 3-4 are now co
rrect in the reprint -- Weak refs are cleared before SoftRefs.
However, lines 8-9 are now wrong, and the following rationale (which wasn't changed) is also incorrect.
Weak refs are intended for canonical mappings, and Soft refs are intended for memory sensitive caches, as stated in the first print
ing.
The actual behaviour is that weak refs are cleared as soon as there are no outstanding strong refs to the referent, while soft refs
can stick around as long as the VM can afford to let them -- they are only guaranteed to be cleared when failing to do so would ca
use an OutOfMemoryError.
This means that WeakRefs are useful for canonical mappings, because they'll be valid as long as the referent is referred to elsewhe
re in the heap, but will clear (and thus let you free whatever other objects you were using the canonical mapping to refer to) as s
oon as no other strong refs are outstanding. Soft refs are useful for caches, since they'll stick around as long as the VM doesn't
have a more urgent need for the memory space they're occupying, but will clear as soon as the space is needed to avoid an OOMError
|
Anonymous |
|
| Printed |
Page 276
last line |
Author claims that variables that are atomically assigned are then thread-safe. This
is inaccurate. True, the variable will not risk a corrupt assigment due to being
operated on simultaneously by two threads but due to issues of visiblity w.r.t the
Java Memory Model one thread will not necessarily immediately see changes made by
another (to its own working copy of the variable). The variable could be stale and
thus two threads in the same process can be working as if the variable was set to two
separate values. That's not thread-safe.
|
Anonymous |
|