• http://www.artima.com/designtechniques/threadsafety.html

• RAM to CPU
  
  
  In the above illustration, the the dotted lines represent "Pipelines" queued in the CPU of a computer. 
• Multiprocessing
  
  
  The curly lines in the above image, are the symbolic presentation of threads, running in a process.
• Multithreading
  
  In a multithreading system, one CPU supports many threads running concurrently, in a round-robin fashions. Each process gets a small unit of CPU time ( quantum), usually 10-100 milliseconds. After quantum ends, the process is preempted ("to prevent something from happening ") with an order of  q = 1/ n of cpu time.
  
   
• How round robin managed!
  
  If time slice is infinite : use First-Come-First-Serve
  If time slice too small : through put suffers due to large overhead.

• Codes : The codes guarantees safe execution in multithreading system,  to retrieve fields or objects without corrupting or compromising the properties of the field or objects.  
• Object : The objects maintain a valid state when accessed concurrently by multiple threads in a shared address space. OR, shared data is protected from race condition when accessed by different threads.
• Operation: Thread safe means, guarantying the operation to be free from "race conditions among the threads"  when accessed by multiple threads simultaneously .

• Synchronization:
  • Mutual Exclusion: shared data is serialized ensuring only one thread access at a time.
  • Atomic Operation
    • Shared data would always retain a valid state, with some mutual locking mechanisms during runtime operation, not being affected by the threads.
  • Immutable Objects:
    • read only option.
    • creating new objects instead of modifying existing ones.
• Avoiding Shared state or Include

• Process-based multitasking handles the concurrent execution of programs, as an operation.
• Thread-based multitasking deals, nibbling, with the concurrent execution of pieces of the same program.
• A multithreaded program contains two or more parts that can run concurrently. Each part of such a program is called a thread, and each thread defines a separate path of execution.
  
   
• Multithread :
  • Easier to start , complex to implement
  • Lower  runtime over head
  • Communications among the threads are faster when compared to multiprocess-applications
  • Can't run on distributed system
• Multiprocessing :
  • Process has more over head compared to threads
  • Can run in multiprocessing system.

Such an object would not be thread-safe, because in a multithreaded environment, the object could become corrupted or be observed to have an invalid state. A thread-safe object is one that always maintains a valid state, as observed by other classes and objects, even in a multithreaded environment.

Why worry about thread safety?
There are two big reasons you need to think about thread safety when you design classes and objects in Java:

1. Support for multiple threads is built into the Java language and API

    

2. All threads inside a Java virtual machine (JVM) share the same heap and method area

Because multithreading is built into Java, it is possible that any class you design eventually may be used concurrently by multiple threads. You needn't (and shouldn't) make every class you design thread-safe, because thread safety doesn't come for free. But you should at least think about thread safety every time you design a Java class. You'll find a discussion of the costs of thread safety and guidelines concerning when to make classes thread-safe later in this article.

Given the architecture of the JVM, you need only be concerned with instance and class variables when you worry about thread safety. Because all threads share the same heap, and the heap is where all instance variables are stored, multiple threads can attempt to use the same object's instance variables concurrently. Likewise, because all threads share the same method area, and the method area is where all class variables are stored, multiple threads can attempt to use the same class variables concurrently. When you do choose to make a class thread-safe, your goal is to guarantee the integrity -- in a multithreaded environment -- of instance and class variables declared in that class.

You needn't worry about multithreaded access to local variables, method parameters, and return values, because these variables reside on the Java stack. In the JVM, each thread is awarded its own Java stack. No thread can see or use any local variables, return values, or parameters belonging to another thread.

Given the structure of the JVM, local variables, method parameters, and return values are inherently "thread-safe." But instance variables and class variables will only be thread-safe if you design your class appropriately.