Atomic Access in thread

 !Atomic Access(an atomic action cannot stop in the middle;no side effects of an atomic action are visible until the action is complete):
         !Reads and writes are atomic for reference variables and for most primitive variables and for all variables declared volatile
         !cannot be interleaved,so they can be used without fear of thread interference.however,this does not eliminate all need to synchronize atomic actions,because memory consistency errors are still possible.
           !so using volatile variables reduces the risk of memory consistency errors,because any write to a volatile variable established a happens-before relationship with subsequent reads of that same variable.this means that changes to a volatile variable are always visible to other threads.what's more,it also means that when a thread reads a volatile variable,it sees not just the latest change to the volatile,but also the side effects of the code that led up the change.
           !using simple atomic vatiable access is more efficient than accessing these variables through synchronized code, but requires more care by the programmer to avoid memory consistency errors.whether the extra effort is worthwhile depends on the size and complexity of the application.
!Liveness(a concurrent application's ability to execute in a timely manner is known as its liveness)
  most common kind of liveness problem
   !!deadlock:descrilbes a situation where two or more threads are blocked forever,waiting for each other.(strict rule of courtesy bower!)
   !!starvation and livelock:
      !!!Starvation(describes a situation where a thread is unable to gain regular access to shares resources and is unable to make progress.by "greedy" threads).
      !!!Livelock(left-and-right-move-pass)
!Guarded Blocks(Threads often have to coordinate their actions):？？？？？？???????????
  !!???????????????????????????????????????????????????????????????????????????????????
!Immutable Objects(if its state cannot changed after it is constructed.a sound strategy for creating simple,reliable code.)
 !!are particularly useful in concurrent applications
  !!!decreased overhead due to garbage collection.
  !!!the elimination of code needed to protect mutable objects from corruption.
!High Level Concurrency Objects
 !!Lock Objects:Synchronized code relies on a simple kind of reentrant lock. This kind of lock is easy to use, but has many limitations. More sophisticated locking idioms are supported by the java.util.concurrency.locks package. We won't examine this package in detail, but instead will focus on its most basic interface, Lock.(The biggest advantage of Lock objects over implicit locks is their ability to back out of an attempt to acquire a lock. )
 !!Executors:(In all of the previous examples, there's a close connection between the task being done by a new thread, as defined by its Runnable object, and the thread itself, as defined by a Thread object. This works well for small applications, but in large-scale applications, it makes sense to separate thread management and creation from the rest of the application. Objects that encapsulate these functions are known as executors. The following subsections describe executors in detail.)
  !!!Executor Interfaces:
    !!!!Executor
    !!!!ExecutorService
    !!!!ScheduledExecutorService
  !!!Thread Pools:
   !!!!
!Atomic Variables: