3BChapter 1-Introduction-12B1.3.Risks of Threads 5 1.3.Risks of Threads Java's built-in support for threads is a double-edged sword.While it simplifies the development of concurrent applications by providing language and library support and a formal cross-platform memory model(it is this formal cross-platform memory model that makes possible the development of write-once,run-anywhere concurrent applications in Java),it also raises the bar for developers because more programs will use threads.When threads were more esoteric,concurrency was an "advanced"topic;now,mainstream developers must be aware of thread-safety issues. 1.3.1.Safety Hazards Thread safety can be unexpectedly subtle because,in the absence of sufficient synchronization,the ordering of operations in multiple threads is unpredictable and sometimes surprising.Unsafesequence in Listing 1.1,which is supposed to generate a sequence of unique integer values,offers a simple illustration of how the interleaving of actions in multiple threads can lead to undesirable results.It behaves correctly in a single-threaded environment,but in a multithreaded environment does not. Listing 1.1.Non-thread-safe Sequence Generator. @NotThreadsafe public class Unsafesequence private int value; /*Returns a unique value.* public int getNext(){ return value++; The problem with Unsafesequence is that with some unlucky timing,two threads could call getNext and receive the same value.Figure 1.1 shows how this can happen.The increment notation,nextvalue++,may appear to be a single operation,but is in fact three separate operations:read the value,add one to it,and write out the new value.Since operations in multiple threads may be arbitrarily interleaved by the runtime,it is possible for two threads to read the value at the same time,both see the same value,and then both add one to it.The result is that the same sequence number is returned from multiple calls in different threads. Figure 1.1.Unlucky Execution of Unsafesequence.Nextvalue. value→9 9+1→10 value=10 value→9 9+1→10 value=10 Diagrams like Figure 1.1 depict possible interleavings of operations in different threads.In these diagrams,time runs from left to right,and each line represents the activities of a different thread.These interleaving diagrams usually depict the worst casel2 and are intended to show the danger of incorrectly assuming things will happen in a particular order. [2]Actually,as we'll see in Chapter 3,the worst case can be even worse than these diagrams usually show because of the possibility of reordering. Unsafesequence uses a nonstandard annotation:@NotThreadsafe.This is one of several custom annotations used throughout this book to document concurrency properties of classes and class members.(Other class-level annotations used in this way are @Threadsafe and @Immutable;see Appendix A for details.)Annotations documenting thread safety are useful to multiple audiences.If a class is annotated with @rhreadsafe,users can use it with confidence in a multithreaded environment,maintainers are put on notice that it makes thread safety guarantees that must be preserved,and software analysis tools can identify possible coding errors.3BChapter 1Ͳ IntroductionͲ12B1.3. Risks of Threads 5 1.3. Risks of Threads Java's builtͲin support for threads is a doubleͲedged sword. While it simplifies the development of concurrent applications by providing language and library support and a formal crossͲplatform memory model (it is this formal crossͲplatform memory model that makes possible the development of writeͲonce, runͲanywhere concurrent applications in Java), it also raises the bar for developers because more programs will use threads. When threads were more esoteric, concurrency was an "advanced" topic; now, mainstream developers must be aware of threadͲsafety issues. 1.3.1. Safety Hazards Thread safety can be unexpectedly subtle because, in the absence of sufficient synchronization, the ordering of operations in multiple threads is unpredictable and sometimes surprising. UnsafeSequence in Listing 1.1, which is supposed to generate a sequence of unique integer values, offers a simple illustration of how the interleaving of actions in multiple threads can lead to undesirable results. It behaves correctly in a singleͲthreaded environment, but in a multithreaded environment does not. Listing 1.1. NonǦthreadǦsafe Sequence Generator. @NotThreadSafe public class UnsafeSequence { private int value; /** Returns a unique value. */ public int getNext() { return value++; } } The problem with UnsafeSequence is that with some unlucky timing, two threads could call getNext and receive the same value. Figure 1.1 shows how this can happen. The increment notation, nextValue++, may appear to be a single operation, but is in fact three separate operations: read the value, add one to it, and write out the new value. Since operations in multiple threads may be arbitrarily interleaved by the runtime, it is possible for two threads to read the value at the same time, both see the same value, and then both add one to it. The result is that the same sequence number is returned from multiple calls in different threads. Figure 1.1. Unlucky Execution of UnsafeSequence.Nextvalue. Diagrams like Figure 1.1 depict possible interleavings of operations in different threads. In these diagrams, time runs from left to right, and each line represents the activities of a different thread. These interleaving diagrams usually depict the worst case[2] and are intended to show the danger of incorrectly assuming things will happen in a particular order. [2] Actually, as we'll see in Chapter 3, the worst case can be even worse than these diagrams usually show because of the possibility of reordering. UnsafeSequence uses a nonstandard annotation: @NotThreadSafe. This is one of several custom annotations used throughout this book to document concurrency properties of classes and class members. (Other classͲlevel annotations used in this way are @ThreadSafe and @Immutable; see Appendix A for details.) Annotations documenting thread safety are useful to multiple audiences. If a class is annotated with @ThreadSafe, users can use it with confidence in a multithreaded environment, maintainers are put on notice that it makes thread safety guarantees that must be preserved, and software analysis tools can identify possible coding errors.