Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts

Jan 7, 2016

JVM Heap Memory Architecture

Heap divided into different sections shown below :

YoungGen :

 It is place where lived for short period and divided in two parts:

Eden Space : 

When object created using new keyword memory allocated on this space.

Survivor Space : 

This is the pool which contains objects which have survived after java garbage collection from Eden space.


Tenured Generation : 

This memory pool contains objects which survived after multiple garbage collection means object which survived after garbage collection from Survivor space.

OldGen : 

This pool is basically contain tenured and virtual (reserved) space and will be holding those objects which survived after garbage collection from YoungGen space


Permanent Generation : 

This memory pool as name also says contain permanent class metadata and descriptors information so PermGen space always reserved for classes and those that is tied to the classes for example static members.

 Java8 Update: PermGen is replaced with Metaspace which is very similar. Main difference is that Metaspace re-sizes dynamically i.e., It can expand at runtime. Java Metaspace space: unbounded (default)
 

Code Cache (Virtual or reserved) : 

If you are using HotSpot Java VM this includes code cache area that containing memory which will be used for compilation and storage of native code.



Java.Lang.OutOfMemoryError: PermGen Space

One of the least understood areas by Java Developers is garbage collection. Java Developers feel JVM takes care of garbage collection and they need not worry about memory allocation, deallocation etc. But as the applications grows complex, so does the garbage collection and once it is complex, the performance do get a hit. So it will benefit the Java Developers to understand how garbage collection works and how to fix the ‘Out of Memory’ issues in java. There are 2 quite common ‘Out of Memory’ issues. The 1st one is ‘Heap Size’ and the 2nd one is ‘PermGen Space’.

Permanent Generation and ClassLoaders


Java objects are instantiations of the Java classes. Every time a new java object is created, JVM creates an internal representation of that object and stores it in the heap. If the class is accessed for the first time, then it has to be loaded by the JVM. Class loading is the process of locating the corresponding class file, seeking the file on the disk, loading the file and parsing the structure. It is the ClassLoaders responsibility to ensure proper loading of the classes.Each and every class in the java program needs to be loaded by the same ClassLoader. ClassLoaders are the instances of java.lang.ClassLoader class. For now, ClassLoader loads the java classes in Perm Space.

JVM also creates an internal representation of the java classes and those are stored in the permanent generation. During garbage collection, both java objects and classes are viewed as objects and are garbage collected in the same way. Initially both the java objects and classes are stored in the heap space.
As a performance optimization the permanent generation was created and classes were put into it.Classes are part of our JVM implementation and we should not fill up the Java heap with our data structures. Permanent Generation is allocated outside the heap size. The permanent Generation contains the following class information:

  •     Methods of a class.
  •     Names of the classes.
  •     Constants pool information.
  •     Object arrays and type arrays associated with a class.
  •     Internal objects used by JVM.
  •     Information used for optimization by the compilers.

Now that we understood what Permanent Generation is, let us see what causes the memory issue in this region.

PermGen Space


‘Java.Lang.OutOfMemoryError: PermGen Space’ occurs when JVM needs to load the definition of a new class and there is no enough space in PermGen. The default PermGen Space allocated is 64 MB for server mode and 32 MB for client mode. There could be 2 reasons why PermGen Space issue occurs.

The 1st reason could be your application or your server has too many classes and the existing PermGen Space is not able to accommodate all the classes.

-XX:MaxPermSize=XXXM


If the issue is due to insufficient PermGen Space due to large number of classes, then you can increase the PermGen space by adding the –XX:MaxPermSize=XXm parameter. This will increase the space available for storing the classes and should -XX:MaxPermSize=256m

-XX:+CMSClassUnloadingEnabled


This parameter indicates whether class unloading enabled when using CMS GC. By default this is set to false and so to enable this you need explicitly set the following option in java options.

-XX:+CMSClassUnloadingEnabled

If you enable CMSClassUnloadingEnabled the GC will sweep PermGen, too, and remove classes which are no longer used.This option will work only when UseConcMarkSweepGC is also enabled using the below option.

-XX:+UseConcMarkSweepGC

-XX:+CMSPermGenSweepingEnabled


This parameter indicates whether sweeping of perm gen is enabled. By default this parameter is disabled and so will need to explicitly set this for fine tuning the PermGen issues. This option is removed in Java 6 and so you will need to use -XX:+CMSClassUnloadingEnabled if you are using Java 6 or above. So the options added to resolve the PermGen Space memory issues will look like

-XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC XX:+CMSClassUnloadingEnabled

Memory leaks


And the 2nd reason could be memory leak. How the class definitions that are loaded could can become unused.

Normally in Java, classes are forever. So once the classes are loaded, they stay in memory even if that application is stopped on the server. Dynamic class generation libraries like cglib use lot of PermGen Space since they create a lot of classes dynamically. Heavy use of Proxy classes, which are created synthetically during runtime. It’s easy to create new Proxy classes when a single class definition could be reused for multiple instances.

Spring and Hibernate often makes proxies of certain classes. Such proxy classes are loaded by a classloader. The generated class definitions are never discarded causing the permanent heap space to fill up fast.

For PermGen space issues, you will need identify the cause of leak and fix it. Increasing the PermGen space will not help, it will only delay the issue, since at some point the PermGen space will still be filled up.


Dec 31, 2015

Java 7 Features

Following are some of the cool features introduced on Java 7.

1. Strings in switch Statement

Before JDK 7, only integral types can be used as selector for switch-case statement. In JDK 7, you can use a String object as the selector. For example,
String state = "NEW";

switch (day) {
   case "NEW": System.out.println("Order is in NEW state"); break;
   case "CANCELED": System.out.println("Order is Cancelled"); break;
   case "REPLACE": System.out.println("Order is replaced successfully"); break;
   case "FILLED": System.out.println("Order is filled"); break;
   default: System.out.println("Invalid");
}

equals() and hashcode() method from java.lang.String is used in comparison, which is case-sensitive. Benefit of using String in switch is that, Java compiler can generate more efficient code than using nested if-then-else statement.


2. Type Inference for Generic Instance Creation (Diamond Operator)

You can replace the type arguments required to invoke the constructor of a generic class with an empty set of type parameters (<>) as long as the compiler can infer the type arguments from the context. This pair of angle brackets is informally called the diamond.

For example, consider the following variable declaration:
Map<String, List<String>> myMap = new HashMap<String, List<String>>();

In Java SE 7, you can substitute the parameterized type of the constructor with an empty set of type parameters (<>):
Map<String, List<String>> myMap = new HashMap<>();

Note that to take advantage of automatic type inference during generic class instantiation, you must specify the diamond. In the following example, the compiler generates an unchecked conversion warning because the HashMap() constructor refers to the HashMap raw type, not the
Map<String, List<String>> type:
Map<String, List<String>> myMap = new HashMap(); // unchecked conversion warning


3. Multiple Exception Handling

In JDK 7, a single catch block can handle more than one exception types.
For example, before JDK 7, you need two catch blocks to catch two exception types although both perform identical task:

try {
   ......

} catch(ClassNotFoundException ex) {
   ex.printStackTrace();
} catch(SQLException ex) {
   ex.printStackTrace();
}

In JDK 7, you could use one single catch block, with exception types separated by '|'.

try {
   ......

} catch(ClassNotFoundException|SQLException ex) {
   ex.printStackTrace();
}

By the way, just remember that Alternatives in a multi-catch statement cannot be related by sub classing. For example a multi-catch statement like below will throw compile time error :

try {
   ......

} catch (FileNotFoundException | IOException ex) {
   ex.printStackTrace();
}

Alternatives in a multi-catch statement cannot be related by sub classing, it will throw error at compile time :
java.io.FileNotFoundException is a subclass of alternative java.io.IOException
        at Test.main(Test.java:18)



4. Binary Literals, underscore in literals

In JDK 7, you could insert underscore(s) '_' in between the digits in an numeric literals (integral and floating-point literals) to improve readability. This is especially valuable for people who uses large numbers in source files, may be useful in finance and computing domains. For example,

int billion = 1_000_000_000;  // 10^9
long creditCardNumber =  1234_4567_8901_2345L; //16 digit number
long ssn = 777_99_8888L;
double pi = 3.1415_9265;
float  pif = 3.14_15_92_65f;


5. Binary Literals with prefix "0b"

In JDK 7, you can express literal values in binary with prefix '0b' (or '0B') for integral types (byte, short, int and long), similar to C/C++ language. Before JDK 7, you can only use octal values (with prefix '0') or hexadecimal values (with prefix '0x' or '0X').
int mask = 0b01010000101;
or even better
int binary = 0B0101_0000_1010_0010_1101_0000_1010_0010;

6. The try-with-resources Statement

Prior to Java SE 7, you can use a finally block to ensure that a resource is closed regardless of whether the try statement completes normally or abruptly. The following example uses a finally block instead of a try-with-resources statement:
static String readFirstLineFromFileWithFinallyBlock(String path)
                                                     throws IOException {
    BufferedReader br = new BufferedReader(new FileReader(path));
    try {
        return br.readLine();
    } finally {
        if (br != null) br.close();
    }
}

The try-with-resources statement is a try statement that declares one or more resources. A resource is an object that must be closed after the program is finished with it. The try-with-resources statement ensures that each resource is closed at the end of the statement. Any object that implements java.lang.AutoCloseable, which includes all objects which implement java.io.Closeable, can be used as a resource.

The following example reads the first line from a file. It uses an instance of BufferedReader to read data from the file. BufferedReader is a resource that must be closed after the program is finished with it:
static String readFirstLineFromFile(String path) throws IOException {
    try (BufferedReader br =
                   new BufferedReader(new FileReader(path))) {
        return br.readLine();
    }
}

In this example, the resource declared in the try-with-resources statement is a BufferedReader. The declaration statement appears within parentheses immediately after the try keyword. The class BufferedReader, in Java SE 7 and later, implements the interface java.lang.AutoCloseable. Because the BufferedReader instance is declared in a try-with-resource statement, it will be closed regardless of whether the try statement completes normally or abruptly (as a result of the method BufferedReader.readLine throwing an IOException).


7. Java NIO 2.0

Java SE 7 introduced java.nio.file package and its related package, java.nio.file.attribute, provide comprehensive support for file I/O and for accessing the default file system. It also introduced the Path class which allow you to represent any path in operating system. New File system API complements older one and provides several useful method checking, deleting, copying, and moving files.
Following additional features have been introduced in NIO package.
  • Now you can check if a file is hidden in Java. 
  • You can also create symbolic and hard links from Java code.  
  • JDK 7 new file API is also capable of searching for files using wild cards. 
  • You also get support to watch a directory for changes.

Anyhow it would be recommended to check Java doc of new file package to learn more about this interesting useful feature.


Dec 28, 2015

Java: Finally block

The runtime system always executes the statements within the finally block regardless of what happens within the try block. So it's the perfect place to perform cleanup. The finally block is a key tool for preventing resource leaks. When closing a file or otherwise recovering resources, place the code in a finally block to ensure that resource is always recovered.

When finally will not execute?

    - If the JVM exits while the try or catch code is being executed, then the finally block may not execute. This may happen due to System.exit() call.

    - If the thread executing the try or catch code is interrupted or killed, the finally block may not execute even though the application as a whole continues.

    - If a exception is thrown in finally block and not handled then remaining code in finally block may not be executed.

From the sample code below we can notice that finally block is not executed while JVM exits in catch block.


    public static void main(String[] args)
    {
        try
        {
            System.out.println("IN TRY BLOCK");
            throwsMethod();
        }
        catch (Exception e)
        {
            System.out.println("IN CATCH BLOCK");
            System.exit(0);
        }
        finally
        {
            System.out.println("IN FINALLY BLOCK");
        }
    }
    
    static void throwsMethod() throws Exception
    {
        throw new Exception("Exception thrown manually");
    }

Code output:

IN TRY BLOCK
IN CATCH BLOCK 

Here you can notice, code inside finally block is not executed.


Dec 27, 2015

java.lang.Error

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it. 

A method is not required to declare in its throws clause any subclasses of Error that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur. That is, Error and its subclasses are regarded as unchecked exceptions for the purposes of compile-time checking of exceptions.

 

Error Summary

S.N.Error & Description
1 AbstractMethodError This is Thrown when an application tries to call an abstract method.
2AssertionError This is Thrown to indicate that an assertion has failed.
3 ClassCircularityError This is Thrown when a circularity has been detected while initializing a class.
4 ClassFormatError This is Thrown when the Java Virtual Machine attempts to read a class file and determines that the file is malformed or otherwise cannot be interpreted as a class file.
5 Error This is an Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.
6 ExceptionInInitializerError These are the Signals that an unexpected exception has occurred in a static initializer.
7 IllegalAccessError This is Thrown if an application attempts to access or modify a field, or to call a method that it does not have access to
8 IncompatibleClassChangeError This is Thrown when an incompatible class change has occurred to some class definition.
9 InstantiationError This is Thrown when an application tries to use the Java new construct to instantiate an abstract class or an interface.
10 InternalError This is Thrown to indicate some unexpected internal error has occurred in the Java Virtual Machine.
11 LinkageError The Subclasses of LinkageError indicate that a class has some dependency on another class.
12 NoClassDefFoundError This is Thrown if the Java Virtual Machine or a ClassLoader instance tries to load in the definition of a class and no definition of the class could be found.
13 NoSuchFieldError This is Thrown if an application tries to access or modify a specified field of an object, and that object no longer has that field.
14 NoSuchMethodError This is Thrown if an application tries to call a specified method of a class (either static or instance), and that class no longer has a definition of that method.
15 OutOfMemoryError This is Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.
16 StackOverflowError This is Thrown when a stack overflow occurs because an application recurses too deeply.
17 ThreadDeath This is an instance of ThreadDeath is thrown in the victim thread when the stop method with zero arguments in class Thread is called.
18 UnknownError This is Thrown when an unknown but serious exception has occurred in the Java Virtual Machine.
19 UnsatisfiedLinkError This is Thrown if the Java Virtual Machine cannot find an appropriate native-language definition of a method declared native.
20 UnsupportedClassVersionError This is Thrown when the Java Virtual Machine attempts to read a class file and determines that the major and minor version numbers in the file are not supported.
21 VerifyError This is Thrown when the "verifier" detects that a class file, though well formed, contains some sort of internal inconsistency or security problem.
22 VirtualMachineError This is Thrown to indicate that the Java Virtual Machine is broken or has run out of resources necessary for it to continue operating.

Jan 28, 2014

Creating Singleton class

First let us understand what is singleton pattern.

Singleton pattern is a design pattern that restricts the instantiation of a class to one object. i.e. You can create only one instance for that class and no more instance can be created. So whenever you request for an instance of that class, same instance which ever created initially is retrieved. One best example of singleton class is Logger class.

Now the question is, how to create a singleton class. Of course, there are lot of ways to create such class. Now let's see one of those methods.

1. First of all, you shouldn't allow anyone to create a new instance, i.e. the creation of instance should be restricted to any external entity. Your class should take care of creating instance for this class.

First restriction is to put on constructor level. i.e. Make your constructor as private. So any other class will not have access to this class' constructor.

class MyLogger{

   private MyLogger(){
      //Code
   }
}


2. If you cannot create an instance, then how will you get the instance of this class and how will you access other methods in this class.

So we have to look for other options to access this class. We all know that static methods of a class can be accessed without it's instance. i.e. We can access all static methods using ClassName itself.

Now create a public static method that retrieves the instance for this particular class when ever some one requests for an instance. 

Use a private static variable to store the class instance as following,

private static MyLogger logger = null;

//Static method (make sure your method is public, 
//so it can be accessed from other classes)

public static MyLogger getInstance(){
      if(logger == null){ //logger is null only for first time.
           logger = new MyLogger();
      }
    
    return logger;
}


Here we can see the static method getInstance() checks for instance & creates a new one if there is no existing instance available. If it finds an existing instance, it just returns the same. 

But if we take a closer look, this method doesn't seem to be thread safe. How? Consider there are no instance created for this class. Two new threads executes this method to create instance at the same time. Say, thread1 enters into if(logger==null) condition & before it creates the instance, thread2 also checks the "if" condition. The condition is true and this thread (thread2) too enters into the "if" block. Now these 2 threads are inside the "if" block & now imagine what happens. Yes, you are right. 2 instances of MyLogger is created, which violates the singleton rule.

How can we handle this? Let's keep the instance creation part into synchronized block as given below, so multi thread access is restricted at same time.

public static MyLogger getInstance(){
      if(logger == null){
           synchronized(MyLogger.class){
                  logger = new MyLogger();
           }
      }
    
    return logger;
}


Does this modification resolve the multiple-instance-creation issue? Nope. Why? Think if thread1 & thread2 both are into "if" block. Now thread1 enters into synchronized block, acquires the monitor, locks the class & creates the instance. thread2 waits till thread1 releases the monitor & as it is already inside "if" block, it now enters into synchronized block and creates another instance. How can we handle this?

We have a concept called double-checked-locking, where the check happens before synchronized block & inside synchronized block as given below.


public static MyLogger getInstance(){
      if(logger == null){
           synchronized(MyLogger.class){
                 if(logger == null){
                       logger = new MyLogger();
                 }
           }
      }
    
    return logger;
}


Does it solve the issue? Of course yes. Only the thread that enters first creates the instance & rest of the threads get the already-created instance.

We can get a question here. Why can't we synchronize the whole method itself, while the synchronized block we mentioned above also locks the class anyway? 

It can be done, but if we take a closer look, we can note that the synchronized static method always locks the class (Refer this link) whenever some class requests an instance, which means, the class is locked whenever an instance is requested. But with the double-checked-locking mechanism, the class is locked only once during first instance creation & rest of the calls won't go through the synchronized block.


We can also have other way of creating singleton class as given below.

class MyLogger {
  private static MyLogger logger = new MyLogger();

  private MyLogger(){ }

  public static MyLogger getInstance(){
    return logger;
  }

}



This one is called eager loading, where static blocks will be loaded during class load itself. i.e. even before the request for an instance is arrived.

But our previous example creates instance only when some class requests for it. This one is called Lazy loading. Anyhow, both ways of creating singleton class serves its purpose.

Jan 25, 2014

Synchronization on static method and instance method

Before getting into synchronization concept, lets first understand what is monitor. 

A monitor is a kind of lock that each class owns. And that monitor, at any time can be held only by a single Thread. When a class is instantiated, each instance is allocated with one monitor. 

Consider our class is Student.java 

public class Student{

 public void getStudentName(){
   //Code
 }

  synchronized(this){
     //code
  }
}

When some thread tries to execute the synchronized method/block, first the thread acquires the monitor that belongs to that instance so that the monitor is not available for any other thread of same instance till this thread completes its task and releases the monitor. The monitor could also be released by putting the thread into wait() status. Note here, if a thread acquires the monitor of an instance, then any synchronized block in that instance cannot be accessed by any thread. But anyhow, non synchronized block is still available for access. 

Threads of other instances have access to this synchronized block as each object has its own monitor.


Static synchronized block:
If our Student class has a static synchronized block & any thread try to access this block,  the monitor belongs to the class itself is acquired by the thread that executes the static block. So any thread on any other instances of this class has to wait till this monitor is released. So be cautious while you develop a static synchronized method.

static Synchronized block is given below.

public static synchronized void getStudentDetails(){
   //Code here
}


A class level lock can be made even by following way. They both have similar effect.

public static void getStudentDetails(){
  synchronized(Student.class){
    //Code here
  }

  

Java Thread: Why do we always call start() method, not run() method in thread


We can see both public void run() and public synchronized void start() are methods of Thread class but we always use thread.start() to invoke the thread rather than using thread.run(). Why? The reason is explained below.

When we invoke a thread using start() method, a new thread stack is created and the run() method starts executing in a new thread stack. But if we call the run() method directly, the new thread stack is not created, rather the run() method executes in current thread stack. The following example clearly tells the difference between calling start() & run() methods.

MyThreadClass.java

public class MyThreadClass implements Runnable {

    @Override
    public void run() {
        System.out.println(Thread.currentThread().getName()+" is running.");
    }
}

MainClass.java

public class MainClass {

   public static void main(String[] args) {
        Thread.currentThread().setName("Main Thread");
        System.out.println("This is main thread: "+Thread.currentThread().getName());
      
        MyThreadClass myThread = new MyThreadClass();
        Thread t = new Thread(myThread, "My Thread");
        t.start();
    }
}

Output:

This is main thread: Main Thread //This is instance of main thread.
My Thread is running. //This is new thread instance.


If we call run() method directly, we can clearly see that the output changes as follows:


Output:

This is main thread: Main Thread //This is instance of main thread.
Main Thread is running. //run() is also invoked in main thread stack.