Lecture 17: Sharing Objects in Java

Transcription

1 COMP 150-CCP Concurrent Programming Lecture 17: Sharing Objects in Java Dr. Richard S. Hall Concurrent programming March 25, 2008

2 Reference The content of this lecture is based on Chapter 3 of the Java Concurrency in Practice book by Brian Goetz.

3 Sharing State Previously, we discussed how to prevent multiple threads from accessing shared state at the same time Now we examine techniques for sharing and publishing objects so they can be safely accessed by multiple threads These two issues provide the foundation for creating thread-safe classes and applications

4 Dual Roles of Synchronization The obvious role of synchronized in Java is for providing mutual exclusion It also plays a significant, but subtle role in memory visibility We not only want to prevent multiple threads from modifying the same state at the same time We also want to ensure that when one thread makes changes, that other threads see them

5 Visibility Example public class NoVisibility { private static boolean ready; private static int number; What is the result of executing this program? private static class ReaderThread extends Thread { public void run() { while (!ready) Thread.yield(); System.out.println(number); public static void main(string[] args) { new ReaderThread().start(); number = 42; ready = true;

6 Visibility Example public class NoVisibility { private static boolean ready; private static int number; It could output private static class ReaderThread extends Thread { public void run() { while (!ready) Thread.yield(); System.out.println(number); public static void main(string[] args) { new ReaderThread().start(); number = 42; ready = true;

7 Visibility Example public class NoVisibility { private static boolean ready; private static int number; Or output 0... private static class ReaderThread extends Thread { public void run() { while (!ready) Thread.yield(); System.out.println(number); public static void main(string[] args) { new ReaderThread().start(); number = 42; ready = true;

8 Visibility Example public class NoVisibility { private static boolean ready; private static int number; Or never exit at all. private static class ReaderThread extends Thread { public void run() { while (!ready) Thread.yield(); System.out.println(number); public static void main(string[] args) { new ReaderThread().start(); number = 42; ready = true;

9 Visibility Visibility is subtle because it is counterintuitive For example, you expect that writes should be visible to subsequent reads However, when reads and writes occur in different threads, this is simply not the case There is no guarantee that one thread will ever see the values written by another thread There is no guarantee that events will occur in a given order Why?

10 Visibility Visibility is subtle because it is counterintuitive For example, you expect that writes should be visible to subsequent reads However, when reads and writes occur in different threads, this is simply not the case There is no guarantee that one thread will ever see the values written by another thread There is no guarantee that events will occur in a given order Why? This allows compilers and JVM implementations to take advantage of multiprocessors to improve performance

11 Visibility Visibility issues can be very difficult to discover Inhibit our ability to reason about cause and effect Inhibit our ability to reason about ordering A solution is to always use proper synchronization whenever data is shared across threads Easier than it sounds

12 Visibility As the previous example shows, insufficient synchronization can result in stale data Threads may see out-of-date values unless synchronization is used whenever a variable is accessed Staleness is also not predictable or necessarily all-ornothing 64-bit operations on long or double variables may actually be broken into two 32-bit operations Stale data may result in serious safety or liveness issues Like the possibility that the previous example never exits

13 Visibility Example What can we say about this class? public class MutableInteger { private int value; public int get() { return value; public void set(int value) { this.value = value;

14 Visibility Example It is not thread safe. public class MutableInteger { private int value; public int get() { return value; public void set(int value) { this.value = value;

15 Visibility Example Is it thread safe now? public class MutableInteger { private int value; public int get() { return value; public synchronized void set(int value) { this.value = value;

16 Visibility Example public class MutableInteger { private int value; public synchronized int get() { return value; No. Both methods must be synchronized since they both provide access to the shared variable. public synchronized void set(int value) { this.value = value;

17 Locking and Visibility y = 1 lock M x = 1 unlock M Thread A Everything before the unlock on M......is visible to everything after the lock on M Thread B lock M i = x unlock M j = y

18 Locking and Visibility When thread A executes a synchronized block and subsequently thread B enters a synchronized block guarded by the same lock......then the values of variables that were visible to A prior to releasing the lock are guaranteed to be visible to B upon acquiring the lock i.e., everything A did in or prior to a synchronized block is visible to B when it executes a synchronized block guarded by the same lock Without synchronization, there is no such guarantee

19 Locking and Visibility When thread A executes a synchronized block and subsequently thread B enters a synchronized block guarded by the same lock......then the values of variables that were visible to A prior to releasing the lock are guaranteed to be visible to B upon acquiring the lock i.e., everything A did in or prior to a synchronized block is visible to B when it executes a synchronized block guarded by the same lock Without synchronization, there is no such guarantee This is also why access to shared state must be guarded by the same lock Protecting it with two different locks could result in seeing stale values

20 Locking and Visibility Summary: Locking is not just about mutual exclusion; it is also about memory visibility. To ensure that all threads see the most up-to-date values of shared mutable variables, the reading and writing threads must synchronize on a common lock.

21 Visibility Volatile variables A weaker form of synchronization, ensures that variable updates are propagated predictably Basically, volatile declaration puts compiler and runtime on notice that the variable is shared Thus, operations should not be reordered with other memory operations Additionally, volatile variables are not cached where their values may be hidden from other processors i.e., a read always returns the most recent value

22 Visibility Volatile variables A volatile int behaves similarly to: public class MutableInteger { private int value; public synchronized int get() { return value; Benefits? public synchronized void set(int value) { this.value = value;

23 Visibility Volatile variables A volatile int behaves similarly to: public class MutableInteger { private int value; public synchronized int get() { return value; Benefits? public synchronized void set(int value) { this.value = value; No locking, no blocking, so lighter weight Also extends visibility to all variables prior to writing/reading the volatile variable Thus, it is very similar to entering and leaving a synchronized block

24 Visibility Volatile variables However, the use of volatiles should be limited Code is more fragile and harder to understand than explicit locking Typical proper usage of volatile variables: volatile boolean stop = false;... while (!stop) { dosomething();... Often used for flags to signal life-cycle events

25 Visibility Example Volatile variables Countdown example from Magee & Kramer textbook: public class CountDown implements Runnable { private final static int N = 10; private Thread thread; public void start() { thread = new Thread(this); thread.start(); public void stop() { thread = null; public void run() { int i = N; while (i >= 0) { if (thread == null) return; else if (i == 0) Is this correct? System.out.println("beep"); else if (i > 0) tick(i); i--; private void tick(int i) { System.out.println("tick: " + i); try { Thread.sleep(1000); catch (InterruptedException ex) {

26 Visibility Example Volatile variables Countdown example from Magee & Kramer textbook: public class CountDown implements Runnable { private final static int N = 10; private Thread thread; public void start() { thread = new Thread(this); thread.start(); public void stop() { thread = null; public void run() { int i = N; while (i >= 0) { if (thread == null) return; else if (i == 0) System.out.println("beep"); else if (i > 0) tick(i); i--; No. The stop() method is used to signal count down thread. private void tick(int i) { System.out.println("tick: " + i); try { Thread.sleep(1000); catch (InterruptedException ex) {

27 Visibility Example Volatile variables Countdown example from Magee & Kramer textbook: public class CountDown implements Runnable { private final static int N = 10; private Thread thread; public void start() { thread = new Thread(this); thread.start(); public void stop() { thread = null; public void run() { int i = N; while (i >= 0) { if (thread == null) return; else if (i == 0) How do we fix it? System.out.println("beep"); else if (i > 0) tick(i); i--; private void tick(int i) { System.out.println("tick: " + i); try { Thread.sleep(1000); catch (InterruptedException ex) {

28 Visibility Example Volatile variables Countdown example from Magee & Kramer textbook: public class CountDown implements Runnable { private final static int N = 10; volatile private Thread thread; public void start() { thread = new Thread(this); thread.start(); public void stop() { thread = null; public void run() { int i = N; while (i >= 0) { if (thread == null) return; else if (i == 0) System.out.println("beep"); else if (i > 0) tick(i); i--; Make thread variable volatile. private void tick(int i) { System.out.println("tick: " + i); try { Thread.sleep(1000); catch (InterruptedException ex) {

29 Visibility Volatile variables Are convenient, but have limitations Locking guarantees both visibility and atomicity, but volatile variables guarantee only visibility For example, read-modify-write operations are not atomic, such as the increment operator (e.g., count++) For this, it is better to use atomic variables in java.util.concurrent, which provide read-modify-write methods

30 Visibility Volatile variables Are convenient, but have limitations Locking guarantees both visibility and atomicity, but volatile variables guarantee only visibility For example, read-modify-write operations are not atomic, such as the increment operator (e.g., count++) For this, it is better to use atomic variables in java.util.concurrent, which provide read-modify-write methods You can use volatile variables when Writes to the variable do not depend on its current value (or you can ensure that only a single thread updates its value),

31 Visibility Volatile variables Are convenient, but have limitations Locking guarantees both visibility and atomicity, but volatile variables guarantee only visibility For example, read-modify-write operations are not atomic, such as the increment operator (e.g., count++) For this, it is better to use atomic variables in java.util.concurrent, which provide read-modify-write methods You can use volatile variables when Writes to the variable do not depend on its current value (or you can ensure that only a single thread updates its value), The variable does not participate in invariants with other state variables, and

32 Visibility Volatile variables Are convenient, but have limitations Locking guarantees both visibility and atomicity, but volatile variables guarantee only visibility For example, read-modify-write operations are not atomic, such as the increment operator (e.g., count++) For this, it is better to use atomic variables in java.util.concurrent, which provide read-modify-write methods You can use volatile variables when Writes to the variable do not depend on its current value (or you can ensure that only a single thread updates its value), The variable does not participate in invariants with other state variables, and Locking is not required for any other reason while accessing the variable.

33 Object Publication You publish an object by making it available outside of its current scope e.g., storing a reference in a static variable, returning it from a method, or passing it to a method Must consider which objects you intend to publish and those which you do not Publishing objects unintentionally can compromise encapsulation, consistency, and thread safety If we want to publish objects we want to do so in a thread-safe way Objects published unintentionally are said to have escaped

34 Object Publication Example public static Set<Secret> knownsecrets; public void initialize() { knownsecrets = new HashSet<Secret>(); Public static references are the most direct way to publish an object...

35 Object Publication Example public static Set<Secret> knownsecrets; public void initialize() { knownsecrets = new HashSet<Secret>(); Also publishes any objects reachable from the published object.

36 Object Publication Example class UnsafeStates { private String[] states = new String[] { "AK", "AL"... ; public String[] getstates() { return states; Returning array references also publishes an object...

37 Object Publication Example class UnsafeStates { private String[] states = new String[] { "AK", "AL"... ; public String[] getstates() { return states; This is bad, since the returned array is mutable.

38 Object Publication Need to think explicitly about object publication Publishing an object indirectly publishes all objects reachable from the published object By following some chain of non-private field references and method calls This means that passing references to alien methods is potentially problematic for thread safety A method is alien to class C if it is not fully specified by C This includes methods of other classes as well as overrideable methods (i.e., non-private, non-final) You do not know how the alien code will use the reference

39 Object Publication Example public class Listen { public Listen(EventSource source) { source.registerlistener(new EventListener() { public void onevent(event e) { dosomething(e); ); This is a common event listener pattern in Java...

40 Object Publication Example public class Listen { public Listen(EventSource source) { source.registerlistener(new EventListener() { public void onevent(event e) { dosomething(e); ); This example lets this escape, since inner classes have an implicit reference to this.

41 Object Publication this escape is a special case of object escape Objects are not valid until after their constructor returns, so care must be take to not publish this in the constructor Use a static factory method to avoid this from escaping

42 Object Publication Example public class Listener { private final EventListener listener; private Listener() { listener = new EventListener() { public void onevent(event e) { dosomething(e); ; Perform initialization in static factory method. public static Listener newinstance(eventsource s) { Listener l = new Listener(); s.registerlistener(s.listener); return safe;

43 Thread Confinement One way to avoid concurrency issues is to avoid sharing data among threads If an object is confined to a single thread, then no synchronization is needed Swing uses thread confinement There is often no way to guarantee that an object is confined to a single thread, it is a matter of design Similar to guarding data with locks

44 Thread Confinement Ad-hoc thread confinement Thread confinement is based solely on proper implementation e.g., Swing Not really supported by language features Typically used to implement a single-threaded subsystem For simplicity To avoid deadlock Should be used sparingly, since there is no explicit enforcement

45 Thread Confinement Stack confinement Special case of thread confinement in which an object can only be reached through local variables Less fragile and simpler to maintain than ad-hoc confinement Quite easy for primitive types, but object references requires more effort i.e., no returning references We have seen this in some of our examples and exercises No interference is possible if we do not reference external entities

46 Thread Confinement ThreadLocal variables A special per thread object reference Has getter and setter methods to access an object reference Maintains a separate reference for each thread that uses it Used to prevent sharing of singletons or globals Can also be used to avoid passing a common argument to every method Also useful in cases where you want to have reusable buffers for some operation Widely used in Java EE containers to associate a transaction context with a given thread Easy to abuse by using too many for globals or hidden method arguments Use with care

47 Thread Confinement ThreadLocal example private static ThreadLocal<Connection> connectionholder = new ThreadLocal<Connection>() { public Connection initialvalue() { return DriverManager.getConnection(DB_URL); ; public static Connection getconnection() { return connectionholder.get(); Allows each thread to have its a non-shared database connection...

48 Thread Confinement ThreadLocal example private static ThreadLocal<Connection> connectionholder = new ThreadLocal<Connection>() { public Connection initialvalue() { return DriverManager.getConnection(DB_URL); ; public static Connection getconnection() { return connectionholder.get(); They automatically get their own copy when calling getconnection().

49 Immutability Another way to avoid concurrency issues is to avoid using mutable state An immutable object is one whose state cannot be changed after construction Immutable objects are always thread safe

50 Immutability Another way to avoid concurrency issues is to avoid using mutable state An immutable object is one whose state cannot be changed after construction Immutable objects are always thread safe An object is immutable if Its state cannot be modified after construction, All its fields are final, and It is properly constructed (i.e., this does not escape during construction) Simpler to reasonable about object state Safer to pass to untrusted code

51 Immutability final fields Limited form of C++ const Final fields cannot be modified after initialization Also have special semantics in Java memory model It is good practice to make all fields final unless they explicitly need to be mutable

52 Immutable Example public final class ThreeStooges { private final Set<String> stooges = new HashSet<String>(); public ThreeStooges() { stooges.add("moe"); stooges.add("larry"); stooges.add("curly"); public boolean isstooge(string name) { return stooges.contains(name); Is this class immutable?

53 Immutable Example public final class ThreeStooges { private final Set<String> stooges = new HashSet<String>(); public ThreeStooges() { stooges.add("moe"); stooges.add("larry"); stooges.add("curly"); public boolean isstooge(string name) { return stooges.contains(name); Yes. You can use mutable classes as long as they don't escape and the values don't change.

54 Immutability How useful are immutable objects if their state cannot change?

55 Immutability How useful are immutable objects if their state cannot change? It is still possible to update program state by replacing immutable objects with new instances Example...

56 Immutable Example Recall our unsafe caching factorizer public class CachingFactorizer implements Servlet { private final AtomicReference<BigInteger> lastnumber = new AtomicReference<BigInteger>(); private final AtomicReference<BigInteger[]> lastfactors = new AtomicReference<BigInteger[]>(); public void service(servletrequest req, ServletResponse resp) { BigInteger i = extractfromrequest(req); if (i.equals(lastnumber.get())) encodeintoresponse(resp, lastfactors.get()); else { BigInteger[] factors = factor(i); lastnumber.set(i); lastfactors.set(factors); encodeintoresponse(resp, factors); What was the issue here?

57 Immutable Example Recall our unsafe caching factorizer public class CachingFactorizer implements Servlet { private final AtomicReference<BigInteger> lastnumber = new AtomicReference<BigInteger>(); private final AtomicReference<BigInteger[]> lastfactors = new AtomicReference<BigInteger[]>(); public void service(servletrequest req, ServletResponse resp) { BigInteger i = extractfromrequest(req); if (i.equals(lastnumber.get())) encodeintoresponse(resp, lastfactors.get()); else { BigInteger[] factors = factor(i); lastnumber.set(i); lastfactors.set(factors); encodeintoresponse(resp, factors); The two state values were dependent on each other, but not atomic.

58 Immutable Example Recall our unsafe caching factorizer public class CachingFactorizer implements Servlet { private final AtomicReference<BigInteger> lastnumber = new AtomicReference<BigInteger>(); private final AtomicReference<BigInteger[]> lastfactors = new AtomicReference<BigInteger[]>(); public void service(servletrequest req, ServletResponse resp) { BigInteger i = extractfromrequest(req); if (i.equals(lastnumber.get())) encodeintoresponse(resp, lastfactors.get()); else { BigInteger[] factors = factor(i); lastnumber.set(i); lastfactors.set(factors); encodeintoresponse(resp, factors); So how could immutable objects help us here?

59 Immutable Example Consider this immutable object definition class OneValueCache { private final BigInteger lastnumber; private final BigInteger[] lastfactors; public OneValueCache(BigInteger i, BigInteger[] factors) { lastnumber = i; lastfactors = Arrays.copyOf(factors, factors.length); public BigInteger[] getfactors(biginteger i) { if (lastnumber == null!lastnumber.equals(i)) return null; else return Arrays.copyOf(lastFactors, lastfactors.length); This immutable object holds two values.

60 Immutable Example Consider this immutable object definition class OneValueCache { private final BigInteger lastnumber; private final BigInteger[] lastfactors; public OneValueCache(BigInteger i, BigInteger[] factors) { lastnumber = i; lastfactors = Arrays.copyOf(factors, factors.length); public BigInteger[] getfactors(biginteger i) { if (lastnumber == null Why not!lastnumber.equals(i)) just use the array directly... return null; else return Arrays.copyOf(lastFactors, lastfactors.length);

61 Immutable Example Consider this immutable object definition class OneValueCache { private final BigInteger lastnumber; private final BigInteger[] lastfactors; public OneValueCache(BigInteger i, BigInteger[] factors) { lastnumber = i; lastfactors = Arrays.copyOf(factors, factors.length); public BigInteger[] getfactors(biginteger i) { if (lastnumber == null!lastnumber.equals(i)) return null; else return Arrays.copyOf(lastFactors, lastfactors.length);...or return the array directly?

62 Immutable Example Consider this immutable object definition class OneValueCache { private final BigInteger lastnumber; private final BigInteger[] lastfactors; public OneValueCache(BigInteger i, BigInteger[] factors) { lastnumber = i; lastfactors = Arrays.copyOf(factors, factors.length); public BigInteger[] getfactors(biginteger i) { if (lastnumber == null!lastnumber.equals(i)) return null; else return Arrays.copyOf(lastFactors, lastfactors.length); It would allow the reference to escape.

63 Immutable Example Consider this immutable object definition class OneValueCache { private final BigInteger lastnumber; private final BigInteger[] lastfactors; public OneValueCache(BigInteger i, BigInteger[] factors) { lastnumber = i; lastfactors = Arrays.copyOf(factors, factors.length); public BigInteger[] getfactors(biginteger i) { if (lastnumber == null!lastnumber.equals(i)) return null; else return Arrays.copyOf(lastFactors, lastfactors.length); Ok, so how does this help?

64 Immutable Example Consider this new caching factorizer Is this now thread safe? public class CachingFactorizer implements Servlet { private volatile OneValueCache cache = new OneValueCache(null, null); public void service(servletrequest req, ServletResponse resp) { BigInteger i = extractfromrequest(req); BigInteger[] factors = cache.getfactors(i); if (factors == null) { factors = factor(i); cache = new OneValueCache(i, factors); encodeintoresponse(resp, factors);

65 Immutable Example Consider this new caching factorizer Yes, and no locking. public class CachingFactorizer implements Servlet { private volatile OneValueCache cache = new OneValueCache(null, null); public void service(servletrequest req, ServletResponse resp) { BigInteger i = extractfromrequest(req); BigInteger[] factors = cache.getfactors(i); if (factors == null) { factors = factor(i); cache = new OneValueCache(i, factors); encodeintoresponse(resp, factors);

66 Immutable Example Consider this new caching factorizer Why use volatile? public class CachingFactorizer implements Servlet { private volatile OneValueCache cache = new OneValueCache(null, null); public void service(servletrequest req, ServletResponse resp) { BigInteger i = extractfromrequest(req); BigInteger[] factors = cache.getfactors(i); if (factors == null) { factors = factor(i); cache = new OneValueCache(i, factors); encodeintoresponse(resp, factors);

67 Immutable Example Consider this new caching factorizer Because each thread needs to see the most upto-date value. public class CachingFactorizer implements Servlet { private volatile OneValueCache cache = new OneValueCache(null, null); public void service(servletrequest req, ServletResponse resp) { BigInteger i = extractfromrequest(req); BigInteger[] factors = cache.getfactors(i); if (factors == null) { factors = factor(i); cache = new OneValueCache(i, factors); encodeintoresponse(resp, factors);

68 Immutable Example Consider this new caching factorizer What happens if cache was accessed more than once? public class CachingFactorizer implements Servlet { private volatile OneValueCache cache = new OneValueCache(null, null); public void service(servletrequest req, ServletResponse resp) { BigInteger i = extractfromrequest(req); BigInteger[] factors = cache.getfactors(i); if (factors == null) { factors = factor(i); cache = new OneValueCache(i, factors); encodeintoresponse(resp, factors);

69 Immutable Example Consider this new caching factorizer It would no longer be thread safe... public class CachingFactorizer implements Servlet { private volatile OneValueCache cache = new OneValueCache(null, null); public void service(servletrequest req, ServletResponse resp) { BigInteger i = extractfromrequest(req); BigInteger[] factors = cache.getfactors(i); if (factors == null) { factors = factor(i); cache = new OneValueCache(i, factors); encodeintoresponse(resp, factors);

70 Immutable Example Consider this new caching factorizer You could use stack confinement to save a copy of cache. public class CachingFactorizer implements Servlet { private volatile OneValueCache cache = new OneValueCache(null, null); public void service(servletrequest req, ServletResponse resp) { BigInteger i = extractfromrequest(req); BigInteger[] factors = cache.getfactors(i); if (factors == null) { factors = factor(i); cache = new OneValueCache(i, factors); encodeintoresponse(resp, factors);

71 Safe Publication So, how do we safely publish objects for sharing across threads? Consider an example...

72 Safe Publication Example A simple class to hold an integer value public class Holder { private int n; public Holder(int n) { this.n = n; public void assertsanity() { if (n!= n) throw new AssertionError( "This statement is false.");

73 Safe Publication Example Some class declares a public holder and initializes it public Holder holder; public void initialize() { holder = new Holder(42); Will this work?

74 Safe Publication Example Some class declares a public holder and initializes it public Holder holder; public void initialize() { holder = new Holder(42); Not necessarily. It could be possible for a thread to see holder in a partially constructed state.

75 Safe Publication Example Some class declares a public holder and initializes it public Holder holder; public void initialize() { holder = new Holder(42); Since synchronization was not used to make the Holder instance visible, it is not properly published.

76 Safe Publication Improperly published objects could result in Other threads seeing a stale value for the reference itself (i.e, holder in the example) Other threads could see stale state values inside the referenced object (i.e., inside holder in the example) Other threads may see state values change in unpredictable ways

77 Immutability and Safe Publication Typically, synchronization is needed for safe publication of objects However, immutable objects have a guarantee of initialization safety in the Java memory model Requirements of immutability must be met (i.e., unmodifiable state, all fields final, and proper construction) Immutable objects can be safely published even without synchronization

78 Safe Publication Idioms Mutable objects must be safely published i.e., the reference to the object and the object's state must be made visible to other threads at the same time

79 Safe Publication Idioms Mutable objects must be safely published i.e., the reference to the object and the object's state must be made visible to other threads at the same time Safe publication of a properly constructed object can be accomplished by Initializing an object reference from a static initializer,

80 Safe Publication Idioms Mutable objects must be safely published i.e., the reference to the object and the object's state must be made visible to other threads at the same time Safe publication of a properly constructed object can be accomplished by Initializing an object reference from a static initializer, Storing a reference to it in a volatile field,

81 Safe Publication Idioms Mutable objects must be safely published i.e., the reference to the object and the object's state must be made visible to other threads at the same time Safe publication of a properly constructed object can be accomplished by Initializing an object reference from a static initializer, Storing a reference to it in a volatile field, Storing a reference to it into a final field of a properly constructed object, or

82 Safe Publication Idioms Mutable objects must be safely published i.e., the reference to the object and the object's state must be made visible to other threads at the same time Safe publication of a properly constructed object can be accomplished by Initializing an object reference from a static initializer, Storing a reference to it in a volatile field, Storing a reference to it into a final field of a properly constructed object, or Storing a reference to it into a field that is properly guarded by a lock

83 Safe Publication Idioms Sounds difficult, doesn't it?

84 Safe Publication Idioms Sounds difficult, doesn't it? It is difficult and care is needed, but in practice it can be simplified to some degree For example, using thread-safe collection classes makes it possible to safely publish objects without explicit synchronization in the threads

85 Safe Publication Summary The publication requirements for an object depend on its mutability

86 Safe Publication Summary The publication requirements for an object depend on its mutability Immutable objects can be published through any mechanism

87 Safe Publication Summary The publication requirements for an object depend on its mutability Immutable objects can be published through any mechanism Effectively immutable objects must be safely published

88 Safe Publication Summary The publication requirements for an object depend on its mutability Immutable objects can be published through any mechanism Effectively immutable objects must be safely published Mutable objects must be safely published and must be either thread-safe or guarded by a lock