Useful jvm flags : 

https://blog.codecentric.de/en/page/3/?s=JVM+flags (Very good explanation, read all the 8 parts, it’s interesting)

http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html (JDK 7)

List of flags for garbage collection : 

• http://blog.ragozin.info/2013/11/hotspot-jvm-garbage-collection-options.html (Check the cheat sheet there)

Complete list of VM flags :

1. http://jvm-options.tech.xebia.fr/
2. http://stas-blogspot.blogspot.in/2011/07/most-complete-list-of-xx-options-for.html

Java 9 has come with the changes which will let you fetch the pid of a process. Following code shows how to get a pid with Java 9

ProcessBuilder pb = new ProcessBuilder("notepad");
		        Process p = pb.start();

		 System.out.println("Pid of Process : " + p.getPid());

getPid function internally call getProcessId0 with process’s handle to retrieve pid. getProcessId0 is a native method.

Apart from process id, other targeted changes are :

• Ability to get/set the process name
• Ability to enumerate Java virtual machines and processes to get pid, name, state, and perhaps resource usage
• Api to do “End Process Tree”. 

Thanks Robin for the update, JDK 9 docs are now available here http://download.java.net/jdk9/docs/api/java/lang/ProcessBuilder.html

package com.rpktech.poc;
import java.util.Date;

public enum SingletonWithEnum {
	INSTANCE;	

	private volatile int count;
	private volatile Date date;		

        public int getCount() {	return count;}

	public void setCount(int countParam) { synchronized(this){ count = countParam; }}

	public Date getDate() {  return new Date(date.getTime());}

	public void setDate(Date dateParam) { synchronized(this){ date = (Date) dateParam.clone();}}

	public String printObject() {
		return "Singleton [count=" + getCount() + ", date=" + getDate() + "]";
	}

}

To test it with serialization and de-serialization I have used google’s GSON library.

package com.rpktech.poc;

import java.util.Date;

import com.google.gson.Gson;
import com.google.gson.GsonBuilder;

public class TestSingletonWithEnum{
	public static void main(String[] s)
	{
		SingletonWithEnum object1 = SingletonWithEnum.INSTANCE;

		object1.setCount(5);
		object1.setDate(new Date());		

		Gson gson = new GsonBuilder().create();

		SingletonWithEnum object2 = gson.fromJson(gson.toJson(object1), SingletonWithEnum.class);

		object2.setCount(3);

		if(object1 == object2)
			System.out.println("Same");
		else
			System.out.println("Differnent");

		System.out.println(object1.printObject());
		System.out.println(object2.printObject());

	}
}

Output

Same
Singleton [count=3, date=Thu Feb 12 20:39:47 IST 2015]
Singleton [count=3, date=Thu Feb 12 20:39:47 IST 2015]

Enum is good choice for singleton because :

1. Enum fields will be initialized when INSTANCE is first accessed or when enum is first accessed. So we can achieve lazy initialization functionality by not using INSTANCE until it (singleton object) is required.
2. You can not extend a proper Singleton since it’s supposed to have a private constructor, so using an enum is fine in place of class (Effective Java Item 2: Enforce the singleton property with a private constructor)

1. JEP 102- Process API Updates
2. JEP 143- Improve Contended Locking
3. JEP 158- Unified JVM Logging
4. JEP 165- Compiler Control
5. JEP 197- Segmented Code Cache
6. JEP 199- Smart Java Compilation, Phase Two
7. JEP 201- Modular Source Code
8. JEP 211- Elide Deprecation Warnings on Import Statements
9. JEP 212- Resolve Lint and Doclint Warnings
10. JEP 213- Milling Project Coin
11. JEP 214- Remove GC Combinations Deprecated in JDK 8
12. JEP 216- Process Import Statements Correctly
13. JEP 217- Annotations Pipeline 2.0
14. JEP 219- Datagram Transport Layer Security (DTLS)
15. JEP 220- Modular Run-Time Images
16. JEP 224- HTML5 Javadoc
17. JEP 228- Add More Diagnostic Commands
18. JEP 229- Create PKCS12 Keystores by Default
19. JEP 230- Microbenchmark Suite
20. JEP 231- Remove Launch-Time JRE Version Selection
21. JEP 235- Test Class-File Attributes Generated by javac
22. JEP 236- Parser API for Nashorn
23. JEP 237- Linux/AArch64 Port

class SomeClass {
  private Resource resource = null;
  public Resource getResource() {
    if (resource == null)
      resource = new Resource();
    return resource;
  }
}

As you can see above “resource” will be initialized only when it will be needed. But this will not work in multi-threaded environment. Because multiple threads can be at line 5 at the same time and it will create multiple objects. To prevent this we can use synchronized keyword at the method level but creating “synchronized methods” are bad for performance, it cost more. So next thought comes to put synchronized block inside the function. Now code look like below

class SomeClass {
  private Resource resource = null;
  public Resource getResource() {
    if (resource == null) {
      synchronized(SomeClass.class){
        if (resource == null)
          resource = new Resource();
      }
    }
    return resource;
  }
}

Above code seems certainly better. It synchronizes “resource” so at a time only one thread can enter and initialize the resource. This implementation is called “Double checking lock” or DCL. But this is also having one issue with Java Memory Model. That is partially initialized objects can be returned. DCL has been explained very well in Brain Goetz article here. I will summarize it in the following statement.

When JVM executes multiple instructions, it can rearrange instructions such that actual result will not change but performance will increase. So when doing new Resource(), it can first allocate memory for object, return the reference to that memory location into “resource” variable and then it will start initialization of inner fields by calling constructor of “Resource object”. As the reference is returned before the constructor is called, it will result into partially created object which is undesirable because its a multi-threading environment and other threads can start using that reference when they found it “not null”.

This problem is very rare and it does not come on all the platforms because few JVMs actually implement the JMM properly. But we can overcome this issue by scarifying performance optimization which was happening by reordering of instructions. If we declare our lazy initialized objects to be volatile then JVM will not rearrange the order of instructions. Note that all the fields inside resource should also be volatile. If your resource class is some third party class and internal fields are not volatile then there are still chances of partially constructed objects. So this way we can improve more but it is still not fixed fully. After implementing volatile; now code will look like this

class SomeClass {
  private volatile Resource resource = null;
  public Resource getResource() {
    if (resource == null) {
      synchronized(SomeClass.class){
        if (resource == null)
          resource = new Resource();
      }
    }
    return resource;
  }
}

The above solution(partially fixed) works from Java 1.5 or later. Brain Goetz had written another article in which he showed a fully working solution for lazy initialization. But it works only for static fields where there should be only one instance of the field shared across all the objects like “db connection instance”. Here is the JSR-133 which covers DCL issue and introduced “Demand Holder idiom”. I will summaries it here.

Class initialization is inherently thread-safe and if you can have an object initialized on class initialization the object creation too are thread-safe.

So here is the less complicated solution of Lazy Initialization In Multi-threaded environment for static fields.

class SomeClass {

	  public Resource getResource() {
	    return ResourceHolder.instance;
	  }

	  // Resource Holder
	  private static class ResourceHolder{
	         private static final Resource instance = new Resource();
	  }
}

In above example resource will be only be created when getResource is called first time. As the class initialization is thread-safe so resource creation will automatically be thread-safe. But notice that inner class is static so this instance will be static. Static is must here, we can not remove it to support lazy initialization of non-static fields because if we remove “static” from inner class then we can not write “ResourceHolder.instance”. We have to create an object of that and object creation is not thread-safe only class loading is thread safe. This will also work for lazy initialization of singleton class because internally they have static field.

Note that if you have multiple static fields for lazy initialization then you have to create multiple static inner classes.

Here is the lazily initialized thread-safe singleton class

public class MySingletonClass{

   private MySingletonClass(){

   }
   public static MySingletonClass getInstance(){
         return IntiailizationOnDemandClassHolder.instance;
   }

   private static class IntiailizationOnDemandClassHolder{
         private static final MySingletonClass instance = new MySingletonClass();

   }

}

Tom has compared performance of all the approched in his blog.

This is over 25 times faster on our benchmark!

Above singleton will work fine but still sometimes people want to protect singleton from cloning, reflection and de-serialization & serialization so there will not be more than one objects of a singleton class. My next article will explain that more in detail.

Continue to Safe Singleton

References

• http://www.javaworld.com/article/2074979/java-concurrency/double-checked-locking–clever–but-broken.html
• http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl
• http://stackoverflow.com/questions/5958767/is-double-checked-locking-is-broken-a-java-only-thing?rq=1
• http://stackoverflow.com/questions/4926681/why-is-double-checked-locking-broken-in-java?rq=1
• http://stackoverflow.com/questions/3578604/how-to-solve-the-double-checked-locking-is-broken-declaration-in-java
• http://www.javamex.com/tutorials/double_checked_locking_fixing.shtml
• http://literatejava.com/jvm/fastest-threadsafe-singleton-jvm/

The Java memory model specifies how and when different threads can see values written to shared variables by other threads, and how to synchronize access to shared variables when necessary. Java memory model which was revised in Java 1.5 is still in use in Java 8. Jenkov has explained very well in his article about JMM. Here is the summary from that article :

1. Primitive variables inside thread are not shareable, they are kept in thread-stack which is non-shareable between threads.
2. Objects are created inside heap and heap area is shareable between threads.
3. Object’s member variable are also stored in heap and hence are shareable even though they are primitive. But all the variable declared inside object’s method are local to that method and they will be store in thread-stack.
4. Static variables are also stored into heap along with the class definition.

Heap is shareable so synchronization is required.  Lets first understand the synchronization and how lock works.

Synchronization : In an article of “Brian Goetz”, synchronization is explained like this

Java’s primary tool for rendering interactions between threads predictably is the synchronized keyword. Many programmers think of synchronized strictly in terms of enforcing a mutual exclusion semaphore (mutex) to prevent execution of critical sections by more than one thread at a time. Unfortunately, that intuition does not fully describe what synchronized means.

The semantics of synchronized do indeed include mutual exclusion of execution based on the status of a semaphore, but they also include rules about the synchronizing thread’s interaction with main memory. In particular, the acquisition or release of a lock triggers a memory barrier — a forced synchronization between the thread’s local memory and main memory. When a thread exits a synchronized block, it performs a write barrier — it must flush out any variables modified in that block to main memory before releasing the lock. Similarly, when entering a synchronized block, it performs a read barrier — it is as if the local memory has been invalidated, and it must fetch any variables that will be referenced in the block from main memory.

The proper use of synchronization guarantees that one thread will see the effects of another in a predictable manner.

Below examples will show the visibility of variables in Java Memory Model which was explained by Jenkov in his article.

After reading Richard’s Blog, next question came to my mind, how to prevent the live locks or any other lock and if it happened how application should handle that.

I found this solution given by “Giuseppe Luciano” which shows a way to solve live lock when it happens in application. Here is his solution – A livelock solution. I believe, “Prevention is better than cure, so first developer should try how to avoid the deadlock situation while designing the solution. I read multiple blogs and googled also for finding the techniques to prevent deadlock, everyone was pointing to “order of lock acquisition” but there were 2 blogs who pointed out few more techniques to prevent deadlock and displayed some more situations where deadlock detection may be missed by the developer. These techniques are :

1. Lock Ordering
2. Lock Timeout
3. Deadlock Detection

You can read more about these techniques on Jenkov’s website. Another site explained different scenarios which can cause a deadlock, you can find it on Brian Goetz’s website. It also shows a solution for live lock problem which was discussed in Richard’s Blog.

There are two popular version of JUnit – JUnit 3 and JUnit 4. Below table shows few important differences in these versions . Apart from this there is one more important difference that from JUnit 4.7 parallel execution of JUnit test cases is supported.

JUnit 3.x Sample

import junit.framework.*;
public class MoneyTest extends TestCase {
	private Money f12CHF;			// fixtures
	private Money f14CHF;

	protected void setUp() {		// create the test data
		f12CHF = new Money(12, "CHF");
		f14CHF = new Money(14, "CHF");
	}
   void testAdd() {				// create the test data
		Money expected = new Money(26, “CHF”);
		assertEquals(“amount not equal”,
                     expected,f12CHF.add(f14CHF);
	}
	...
}

JUnit 4.x Sample

import junit.framework.*;
import org.junit.*;
import static org.junit.Assert.*;
public class MoneyTest <del>extends TestCase</del> {
	private Money f12CHF;
	private Money f14CHF;

	@Before
        public void setUp() // setup, teardown function names are not mandatory now as we have annotations now
        {
		f12CHF = new Money(12, "CHF");    // - the fixture
		f14CHF = new Money(14, "CHF");
	}
	@Test
        public void testAdd() // create the test data
        {
		Money expected = new Money(26, “CHF”);
		assertEquals(“amount not equal”,
                     expected,f12CHF.add(f14CHF));
	}
	...
}

Following changes were happened in JUnit 4.x

1. No need to start test method name with prefix “test”.
2. @BeforeClass and @AfterClass were introduced
   1. @BeforeClass method – executes only once; before the first test method
   2. @AfterClass method – executes only once; after the last test method
3. Instead of setup and tearDown now JUnit 4 has @Before and @After annotations.
   1. @Before method – executes every time; before the test method.
   2. @After method – executes every time; after the test method.
4. @Ignore was introduced to skip a test case while running.
5. “expected” was introduced to tell JUnitRunner that what exception we are expecting. Example : @Test(expected=ArithmeticException.class)
6. “timeout” was introduced to put a time limit on a testcase. If test does not complete in that time limit, an exception will raise with message “test timed out after xxx milliseconds”

Next posts will show the working examples with these annotations.