Preventing Memery Locks on the Multi CPU machine

Problem
   Multithreaded apps create new objects at the same time
   New objects are always created in the EDEN space
   During object creation, memory is locked
   On a multi CPU machine (threads run concurrently) there can be contention

Solution
    Allow each thread to have a private piece of the EDEN
    space
Thread Local Allocation Buffer
    -XX:+UseTLAB
    -XX:TLABSize=
    -XX:+ResizeTLAB
    (On by default on multi CPU machines and newer JDK)
Analyse TLAB usage
    -XX:+PrintTLAB
JDK 1.5 and higher (GC ergonomics)
    Dynamic sizing algorithm, tuned to each thread

INSIDE THE JAVA VIRTUAL MACHINE / Filip Hanik

Sun recommended JVM Settings

GC Settings
   -XX:+UseConcMarkSweepGC
   -XX:+CMSIncrementalMode
   -XX:+CMSIncrementalPacing
   -XX:CMSIncrementalDutyCycleMin=0
   -XX:+CMSIncrementalDutyCycle=10
   -XX:+UseParNewGC
   -XX:+CMSPermGenSweepingEnabled
To analyze what is going on
   -XX:+PrintGCDetails
   -XX:+PrintGCTimeStamps
   -XX:-TraceClassUnloading
                                   
Minor Notes
-XX:+UseParallelGC <> -XX:+UseParNewGC
-XX:ParallelGCThreads=
    Use with ParallelGC setting
If you have 4 cpus and 1 JVM
    Set value to 4
If you have 4 cpus and 2 JVM
    Set value to 2
If you have 4 cpus and 6 JVM
    Set value to 2

INSIDE THE JAVA VIRTUAL MACHINE / Filip Hanik

Thread Safety Rules

Safety Rules

Sometimes, a set of data is interdependent. For example, we might have two fields corresponding to a street address and a zip code. Changing an address might involve changing both of these fields. If the zip code is changed without a corresponding change to the street address, the data may be inconsistent or incoherent. Such a set of operations, which must be done as a unit -- i.e., either all of the operations are executed or none are -- in order to ensure consistency of the data, is called a transaction. The property of "doing all or none" is called atomicity. A system in which all transactions are atomic is transaction-safe.
The following rule suffices to ensure that your system is transaction-safe:

All (potentially changeable) shared data is accessed only through the synchronized methods of a single object; no interdependent piece can be accessed independently.

Note that this means that shared data cannot be returned by these methods for access by other methods. If shared data is to be returned, a (non-shared) copy must be made. Further, if interdependent values are to be returned (i.e., a portion of the shared data is to be used by other methods), all of the relevant values must be returned in a single transaction.
For example, the address and zip code of the previous example should not be returned by two separate method calls if they are to be assumed consistent.

public class AddressData {

private String streetAddress;
private String zipCode;
public AddressData( String streetAddress, String zipCode) {
    this.setAddress( streetAddress, zipCode );
    ....
}
public synchronized void setAddress( String streetAddress,
                                     String zipCode) {
    // validity checks
    ....
    // set fields
    ....
}
public synchronized String getStreetAddress() { // problematic!
    return this.streetAddress;
}
public synchronized String getZipCode() { // problematic!
    return this.zipCode;
}

}

If this class definition were used, e.g. for

printMailingLabel( address.getStreetAddress(),
                   address.getZipCode() );

it would in principle be possible to get an inconsistent address. For example, between the calls to address.getStreetAddress() and address.getZipCode(), it is possible that a call to address.setAddress could occur. In this case, getStreetAddress would return the old street address, while getZipCode() would return the new zip code.
Instead, getStreetAddress() and getZipCode() should be replaced by a single synchronized method which returns a copy of the fields of the AddressData object:

public synchronized SimpleAddressData getAddress() {
    return new SimpleAddressData( this.streetAddress,
                                  this.zipCode );
}

The SimpleAddressData class can contain just public streetAddress and zipCode fields, without accessors. It is being used solely to return the two objects at the same time.

Introduction to Interactive Programming by Lynn Andrea Stein

Reentrant Synchronization

Recall that a thread cannot acquire a lock owned by another thread. But a thread can acquire a lock that it already owns. Allowing a thread to acquire the same lock more than once enables reentrant synchronization. This describes a situation where synchronized code, directly or indirectly, invokes a method that also contains synchronized code, and both sets of code use the same lock. Without reentrant synchronization, synchronized code would have to take many additional precautions to avoid having a thread cause itself to block.

Intrinsic Locks and Synchronization

Cooperation

Java's monitor supports two kinds of thread synchronization: mutual exclusion and cooperation . Mutual exclusion, which is supported in the Java virtual machine via object locks, enables multiple threads to independently work on shared data without interfering with each other. Cooperation, which is supported in the Java virtual machine via the wait and notify methods of class Object, enables threads to work together towards a common goal. 

Cooperation is important when one thread needs some data to be in a particular state and another thread is responsible for getting the data into that state. For example, one thread, a "read thread," may be reading data from a buffer that another thread, a "write thread," is filling. The read thread needs the buffer to be in a "not empty" state before it can read any data out of the buffer. If the read thread discovers that the buffer is empty, it must wait. The write thread is responsible for filling the buffer with data. Once the write thread has done some more writing, the read thread can do some more reading. 

Thread Synchronization by Bill Venner

package monitor;
import java.util.Vector;



class Producer extends Thread {
    static final int MAXQUEUE = 5;
    private Vector messages = new Vector(); 

    public void run() {

        try {
         while ( true ) {
                putMessage();
                sleep( 1000 );
            }
        }
        catch( InterruptedException e ) { }
    }

    private synchronized void putMessage() throws InterruptedException {
        while ( messages.size() == MAXQUEUE )
            wait();
        messages.addElement( new java.util.Date().toString() );
        notify();
    }

    // Called by Consumer
    public synchronized String getMessage() throws InterruptedException {
       notify();
       while ( messages.size() == 0 )
            wait();
        String message = (String)messages.firstElement();
        messages.removeElement( message );
        return message;
    }

}



class Consumer extends Thread {
    Producer producer;

    Consumer(Producer p) {
        producer = p;
    }

    public void run() {
        try {
            while ( true ) {
                String message = producer.getMessage();
                System.out.println("Got message: " + message);
                sleep( 2000 );
            }
        }
        catch( InterruptedException e ) { }
    } 

    public static void main(String args[]) {
        Producer producer = new Producer();
        producer.start();
        new Consumer( producer ).start();
    }

}