Suppose foo is a variable of type long. The following operation is not an atomic operation:

foo = 65465498L;

Indeed, the variable is written using two separate operations: one that writes the first 32 bits, and a second one which writes the last 32 bits. That means that another thread might read the value of foo, and see the intermediate state.

Making the operation atomic consists in using synchronization mechanisms in order to make sure that the operation is seen, from any other thread, as a single, atomic (i.e. not splittable in parts), operation. That means that any other thread, once the operation is made atomic, will either see the value of foo before the assignment, or after the assignment. But never the intermediate value.

A simple way of doing this is to make the variable volatile:

private volatile long foo;

Or to synchronize every access to the variable:

public synchronized void setFoo(long value) {
    this.foo = value;
}

public synchronized long getFoo() {
    return this.foo;
}
// no other use of foo outside of these two methods, unless also synchronized

Stack

  1. The stack is the memory set aside as scratch space for a thread of execution. When a function is called, a block is reserved on the top of the stack for local variables and some bookkeeping data.
  2. When that function returns, the block becomes unused and can be used the next time a function is called. The stack is always reserved in a LIFO (last in first out) order;
  3. the most recently reserved block is always the next block to be freed. This makes it really simple to keep track of the stack; freeing a block from the stack is nothing more than adjusting one pointer.

Heap

  1. The heap is memory set aside for dynamic allocation. Unlike the stack, there’s no enforced pattern to the allocation and deallocation of blocks from the heap;
  2. you can allocate a block at any time and free it at any time. This makes it much more complex to keep track of which parts of the heap are allocated or free at any given time
  3. There are many custom heap allocators available to tune heap performance for different usage patterns.

Each thread gets a stack, while there’s typically only one heap for the application

Which is faster – the stack or the heap? And why?
The stack is much faster than the heap. This is because of the way that memory is allocated on the stack. Allocating memory on the stack is as simple as moving the stack pointer up.

Where are the stack and heap stored?
Both stored in the computer’s RAM (Random Access Memory).

What is stored in stack and heap ?
Stack – Primitives, Calls to methods are stored on the stack
Heap – Class objects including method code and static fields in the heap space.

What determines the size of each of them?
The size of the stack is set when a thread is created. The size of the heap is set on application startup, but can grow as space is needed.

How do the stack and heap work in multithreading?
In a multi-threaded application, each thread will have its own stack. But, all the different threads will share the heap. Because the different threads share the heap in a multi-threaded application, this also means that there has to be some coordination between the threads so that they don’t try to access and manipulate the same piece(s) of memory in the heap at the same time.


How long does memory on the stack last versus memory on the heap?

Once a function call runs to completion, any data on the stack created specifically for that function call will automatically be deleted. Any data on the heap will remain there until it’s manually deleted by the programmer.

Can the stack grow in size? Can the heap grow in size?
The stack is set to a fixed size, and can not grow past it’s fixed size. So, if there is not enough room on the stack to handle the memory being assigned to it, a stack overflow occurs. This often happens when a lot of nested functions are being called, or if there is an infinite recursive call.

If the current size of the heap is too small to accommodate new memory, then more memory can be added to the heap by the operating system. This is one of the big differences between the heap and the stack.

Q1.Explain Exception Hierachy?

Q2.What are important methods of Java Exception Class?
String getMessage() – This method returns the message String of Throwable and the message can be provided while creating the exception by it’s constructor.
String getLocalizedMessage() – This method is provided so that subclasses can override it to provide locale-specific message to the calling program. Throwable class implementation of this method simply uses getMessage() method to return the exception message.
synchronized Throwable getCause() – This method returns the cause of the exception or null id the cause is unknown.
void printStackTrace() – This method prints the stack trace information to the standard error stream, this method is overloaded and we can pass PrintStream or PrintWriter as an argument to write the stack trace information to the file or stream.

Q3.What is multi-catch block?(or) How can I catch multiple Java exceptions in the same catch clause?
We can catch multiple exceptions in a single catch block. catching all the exceptions in a single try block, you will notice that catch block code looks very ugly and mostly consists of redundant code to log the error, keeping this in mind Java 7 one of the features was multi-catch block.

catch(IOException | SQLException | Exception ex){
     logger.error(ex);
     throw new MyException(ex.getMessage());
}

Q4.What is try-with-resources does?
try-with-resources was introduced because some resources used in Java (like SQL connections or streams) being difficult to be handled properly; as an example, in java 6 to handle a InputStream properly you had to do something like

InputStream stream = new MyInputStream(...);
try {
    // ... use stream
} catch(IOException e) {
   // handle exception
} finally {
    try {
        if(stream != null) {
            stream.close();
        }
    } catch(IOException e) {
        // handle yet another possible exception
    }
}

Using try-with-resources we can do the same thing as below and close() is automatically called, if it throws an IOException, it will be supressed

try (InputStream stream = new MyInputStream(...)){
    // ... use stream
} catch(IOException e) {
   // handle exception
}

Any object that implements java.lang.AutoCloseable, which includes all objects which implement java.io.Closeable, can be used as a resource.

Q5.Advantages of try-with-resources does?

  1. Readable code and easy to write and Number of lines of code is reduced as no need for finally block
  2. We can open multiple resources in try-with-resources statement separated by a semicolon. For example, we can write following code.
  3. When multiple resources are opened in try-with-resources, it closes them in the reverse order to avoid any dependency issue. You can extend my resource program to prove that.
  4. Automatic resource management.

Q6.What is Exception Masking?
When code in a try block throws an exception, and the close method in the finally also throws an exception, the exception thrown by the try block gets lost and the exception thrown in the finally gets propagated. This is usually unfortunate, since the exception thrown on close is something unhelpful while the useful exception is the informative one. Using try-with-resources to close your resources will prevent from exception-masking from taking place.With try-with-resources, if the try block throws an exception and the close method also throws an exception, then the exception from the close block gets tacked on to the original exception. the exception from the finally block is added to the list of exceptions suppressed by the exception from the try block. As an exception unwinds the stack, it can accumulate multiple suppressed exceptions.On the other hand if your code completes normally but the resource you’re using throws an exception on close, that exception (which would get suppressed if the code in the try block threw anything) gets thrown.

Q7.How Autocloseable works?
A try-with-resources statement makes sure that all declared resources will be closed at the end of the statement.To close a resource its should implement the AutoCloseable interface Object of classes that implements autoCloseable are considered for deallocation in try-with-resources.JVM will call close() automatically for you

public class MyResource implements AutoCloseable 
{
    public void close() throws Exception 
    {
        System.out.println("Closing!");
    }
}

try(MyResource res = new MyResource()) 
{
    //use res here
}

Q8.Difference between Closeble and Autocloseable works?
Closeable.close() throws IOException. A lot of close() methods that could benefit of try-with-resources throw other checked exceptions (eg java.sql.Connection.close() so AutoCloseable.close() throws Exception. Changing the existing Closeable contract would break all existing applications/library relying on the contract that close() only throws IOException and not all (checked) exceptions.

Q9.How to get Suppressed Exceptions?
java 7 functionality has been provided to retrieve suppressed Exceptions. You can call public final java.lang.Throwable[] getSuppressed() function on the catched throwable object to view the suppressed Exceptions.

public final void addSuppressed(Throwable exception)
Appends the specified exception to the exceptions that were suppressed in order to deliver this exception.

public final Throwable[] getSuppressed()
Returns an array containing all of the exceptions that were suppressed, typically by the try-with-resources statement, in order to deliver this exception.

public static  T suppress(final T t, final Throwable suppressed) 
public static Throwable [] getSuppressed(final Throwable t) {

addSuppressed Example

public static void memberFunction() throws Exception
    {
        Throwable th = null;
        DirtyResource resource= new DirtyResource();
        try
        {
              resource.accessResource();
        }
        catch(Exception e)
        {
            th = e;
        }
        finally
        {
            try
            {
                resource.close();
            }
            catch(Exception e)
            {
                if(th != null)
                {
                    e.addSuppressed(th); //Add to primary exception
                    throw e;
                }
            }
        }
    }

getSuppressed Example

 public static void main(String[] arguments) throws Exception
   {
      try
      {
          memberFunction();
      }
      catch(Exception ex)
      {
          err.println("Exception encountered: " + ex.toString());
          final Throwable[] suppressedExceptions = ex.getSuppressed();
          final int numSuppressed = suppressedExceptions.length;
          if (numSuppressed > 0)
          {
              err.println("tThere are " + numSuppressed + " suppressed exceptions:");
              for (final Throwable exception : suppressedExceptions)
              {
                  err.println("tt" + exception.toString());
              }
          }
      }
   }

Errors vs Exception
Errors should not be caught or handled.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.
i.e AnnotationFormatError, AssertionError, LinkageError, VirtualMachineError

Example: OutOfMemoryError – Not much you can do as your program can no longer run.

Exceptions are often recoverable and even when not, they generally just mean an attempted operation failed, but your program can still carry on.

Example: IllegalArgumentException – Passed invalid data to a method so that method call failed, but it does not affect future operations.

What is difference between Checked Exception and Unchecked Exception?
Checked Exception
The classes that extend Throwable class except RuntimeException and Error are known as checked exceptions e.g.IOException,SQLException etc. Checked exceptions are checked at compile-time.

Unchecked Exception
The classes that extend RuntimeException are known as unchecked exceptions e.g. ArithmeticException,NullPointerException etc. Unchecked exceptions are not checked at compile-time.

Is it necessary that each try block must be followed by a catch block?
It is not necessary that each try block must be followed by a catch block. It should be followed by either a catch block OR a finally block. And whatever exceptions are likely to be thrown should be declared in the throws clause of the method.

Can finally block be used without catch?
Yes, by try block. finally must be followed by either try or catch

Is there any case when finally will not be executed?
finally block will not be executed if program exits(either by calling System.exit() or by causing a fatal error that causes the process to abort).

Can subclass overriding method declare an exception if parent class method doesn’t throw an exception ?
Yes but only unchecked exception not checked.

What is exception propagation ?
Forwarding the exception object to the invoking method is known as exception propagation. By default Unchecked Exceptions are forwarded in calling chain (propagated).

 
 Method1()  //Exception Occured
 Method2()
 Method3()
 main()

In the above example exception occurs in Method1() method where it is not handled,so it is propagated to previous Method2() method where it is not handled, again it is propagated to Method3() before main method where exception is handled.

Static methods cannot be overridden but can be redefined in child Class

class Animal 
{
  static void doStuff() 
  {
    System.out.print("animal");
  }
}

class Dog extends Animal 
{
   // it's a redefinition
   // not an override
   static void doStuff() 
   { 					
     System.out.print("dog");
   }

   public static void main(String [] args) 
   {
      Animal [] a = {new Animal(), new Dog(), new Animal()};
     
      for(int x = 0; x < a.length; x++)
     	a[x].doStuff();               // invoke the static method 

    }
}

Output

animal animal animal

Method overriding is made possible by dynamic dispatching, meaning that the declared type of an object doesn’t determine its behavior, but rather its runtime type

Animal lassie = new Dog();
lassie.speak(); // outputs "woof!"
Animal kermit = new Frog();
kermit.speak(); // outputs "ribbit!"

Even though both lassie and kermit are declared as objects of type Animal, their behavior (method .speak()) varies because dynamic dispatching will only bind the method call .speak() to an implementation at run time – not at compile time.

Now, here’s where the static keyword starts to make sense: the word “static” is an antonym for “dynamic”. So the reason why you can’t override static methods is because there is no dynamic dispatching on static members – because static literally means “not dynamic”. If they dispatched dynamically (and thus could be overriden) the static keyword just wouldn’t make sense anymore.

public class Why {

  public static void test() {
    System.out.println("Passed");
  }

  public static void main(String[] args) {
    Why NULL = null;
    NULL.test();
  }
}

test() is a static method. A static member belongs to the type, and do not require an instance to access.

A static member should ONLY be accessed via a type expression. That is, you should’ve written it as follows:

Why.test(); // always invoke static method on the type it belongs to!

Java does allow you to access a static member via an object reference expression, but this is VERY misleading, since this is NOT the actual semantics of a static member access.

Why aNull = null; 
aNull.test(); // DO NOT EVER DO THIS!
// invokes Why.test(), does NOT throw NullPointerException

When accessing a static member through an object reference expression, only the declared type of the reference matters. This means that:

  1. It doesn’t matter if the reference is actually null, since no instance is required
  2. If the reference is not null, it doesn’t matter what the runtime type of the object is, there is no dynamic dispatch!!!

What is Serialization?
Serialization is the conversion of an object to a series of bytes, so that the object can be easily saved to persistent storage or streamed across a communication link.The byte stream can then be deserialized – converted into a replica of the original object.In Java, the serialization mechanism is built into the platform, but you need to implement the Serializable interface to make an object serializable.

You can also prevent some data in your object from being serialized by marking the attribute as transient.

Finally you can override the default mechanism, and provide your own; this may be suitable in some special cases.

private void writeObject(ObjectOutputStream out) throws IOException;
private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException;

This way you can create your own custom serialization to make it more “whatever” (safe, fast, rare, easy etc. )

It is important to notice that what gets serialized is the “value” of the object, or the contents, and not the class definition.

import java.util.*;

// This class implements "Serializable" to let the system know
// it's ok to do it. You as programmer are aware of that.
public class SerializationSample implements Serializable {

    // These attributes conform the "value" of the object.

    // These two will be serialized;
    private String aString = "The value of that string";
    private int    someInteger = 0;

    // But this won't since it is marked as transient.
    private transient List<File> unInterestingLongLongList;

    // Main method to test.
    public static void main( String [] args ) throws IOException  { 

        // Create a sample object, that contains the default values.
        SerializationSample instance = new SerializationSample();

        // The "ObjectOutputStream" class have the default 
        // definition to serialize an object.
        ObjectOutputStream oos = new ObjectOutputStream( 
                               // By using "FileOutputStream" we will 
                               // Write it to a File in the file system
                               // It could have been a Socket to another 
                               // machine, a database, an in memory array, etc.
                               new FileOutputStream(new File("o.ser")));

        // do the magic  
        oos.writeObject( instance );
        // close the writing.
        oos.close();
    }
}

Real World Example
ATM: When the account holder tries to withdraw money from the server through ATM, the account holder information like withdrawl details will be serialized and sent to server where the details are deserialized and used to perform operations.

How serialization is performed in java.

  1. Implement “java.io.Serializable” interface.(marker interface so no method to implement)
  2. Persist the object : Use java.io.ObjectOutputStream class, a filter stream which is a wrapper around a lower-level byte stream. (to write Object to file systems or transfer a flattened object across a network wire and rebuilt on the other side.)
    1. writeObject(<>) – to write an object
    2. readObject() – to read an serialized Object

When you serialize an object, only the object’s state will be saved, not the object’s class file or methods.

What are the Steps when object is serialized and de-serialized?

  1. First writes the serialization stream magic data
  2. Then it writes out the metadata of the class associated with an instance.( length of the class, the name of the class, serialVersionUID)
  3. Then it recursively writes out the metadata of the superclass until it finds java.lang.object.
  4. Then starts with the actual data associated with the instance.
  5. Finally writes the data of objects associated with the instance starting from metadata to actual content.

How not to serialize any field in class.
Use transient keyword

When child class is serialized does parent class get serialized?
No, Only meta data of parents get serialized till object class.

When parent is serialized does child class get serialized?
Yes, by default child class also get serialized.

How to avoid child class from getting serialized?
Override writeObject and readObject method and throw NotSerializableException exception.also you can mark all fields transient in child class.

Some system-level classes such as Thread, OutputStream, and its subclasses, and Socket are not serializable.

If you have a child class which implements serializable and parent class is not serializable then parent class will be reset to the values they were given during the original construction of the object

 
class Cat
{ 
 public String name = "Cat";
} 

class Tiger extends Cat implements Serializable 
{ 
 public int weight; 

 Tiger(int pWeight, String pName)
 {
   name   = pName;
   weight = pWeight;
 }
} 

class SerialTest
{
 public static void main(String args[])
 {
   Tiger  objTiger = new Tiger(150, "Bengal");
   sysout("Before Serialization : Weight -"+ objTiger.getWeight + " Name -"+ objTiger.getName); 
 }
 
}

Output

 Before Serialization : Weight - 150 Name - Bengal 
 After Serialization : Weight - 150  Name - Cat

After serialization the Parent class Cat Name would be set to Original name which is Cat.This is because non-serializable class constructor will run.

 class Animal implements Serializable
 { 
   transient String swims = "Y";
 }

When the Animal has deserialized the value of swims would be set to null since it is marked as transient.

If you serialize a collection(ArrayList, LinkedList) or an array, every element must be Serializable. If any element in the collection is non-serializable then serialization fails. Collection interfaces are non serializable(List,Map) whereas concrete collection classes are serializable(ArrayList, LinkedList)

Static Variables are not serializable
Static variables are not saved as part of object state because they do not belong to object they belong to Class

What are serializable and not serializable

  1. Instance Variables: These variables are serialized, so during deserialization we will get back the serialized state.
  2. Static Variables: These variables are not serialized, So during deserialization static variable value will loaded from the class.(Current value will be loaded.)
  3. transient Variables: transient variables are not serialized, so during deserialization those variables will be initialized with corresponding default values (ex: for objects null, int 0).
  4. Super class variables: If super class also implemented Serializable interface then those variables will be serialized, otherwise it won’t serialize the super class variables. and while deserializing, JVM will run default constructor in super class and populates the default values. Same thing will happen for all superclasses.

I have a scenario where a scheduled job being run by Quartz will update an arraylist of objects every hour.

But I need this arraylist of objects to be visible to all sessions created by Tomcat. So what I’m thinking is that I write this object somewhere every hour from the Quartz job that runs so that each session can access it.

Store the list in the ServletContext as an application-scoped attribute. Pulling the data from a database instead is probably less efficient, since you’re only updating the list every hour. Creating a ServletContextListener might be necessary in order to give the Quartz task a reference to the ServletContext object. The ServletContext can only be retrieved from JavaEE-related classes like Servlets and Listeners.In the ServletContextListener, when you create the job, you can pass the list into the job by adding it to a JobDataMap.

public class MyServletContextListener implements ServletContextListener{
  public void contextInitialized(ServletContextEvent event){
    ArrayList list = new ArrayList();

    //add to ServletContext
    event.getServletContext().setAttribute("list", list);

    JobDataMap map = new JobDataMap();
    map.put("list", list);
    JobDetail job = new JobDetail(..., MyJob.class);
    job.setJobDataMap(map);
    //execute job
  }

  public void contextDestroyed(ServletContextEvent event){}
}

//Quartz job
public class MyJob implements Job{
  public void execute(JobExecutionContext context){
    ArrayList list = (ArrayList)context.getMergedJobDataMap().get("list");
    //...
  }
}

Publishing attributes via ServletContext#setAttribute is thread-safe! This can be derived from the Java Servlet Specification, chapter 4.5: (…) Any attribute bound into a context is available to any other servlet that is part of the same Web application.(…).

(Reason: Making objects available to other servlets means also to make them available to other threads. This is only possible, if proper synchronization is used, so synchronization is mandatory for ServletContext#setAttribute).

So the same is also true for reading published attributes via ServletContext#getAttribute.

Note
But if an object like a HashMap is shared between different threads, the developer must ensure that this shared object itself is accessed in a proper, thread-safe way! Using a ConcurrentHashMap is a possible solution, but does not solve the race condition when the attribute is initialized, as the null check will not be atomic.

ConcurrentMap<String, Object> shared = (...)servletContext.getAttribute("sharedData");
if (shared == null) {
    shared = new ConcurrentHashMap<>();
    servletContext.setAttribute("sharedData", shared);
}

Context is stored at the application level scope where as request is stored at page level.If you use an absolute path(full path) such as (“http://www.computerhope.com/jargon/a/index.jsp”), there is no difference.

If you use relative path, you must use HttpServletRequest.getRequestDispatcher(). ServletContext.getRequestDispatcher() doesn’t allow it.

RequestDispatcher dispatcher = 
        request.getRequestDispatcher("index.jsp");
    dispatcher.forward( request, response ); 

Will forward the request to the page http://example.com/myapp/subdir/index.jsp

request.getSession() will return a current session. if current session will not exist the it will create a new one.

request.getSession(true) will return current session. If current session will not exist then it will create new session.

So basically there is not difference between both method.

request.getSession(false) will return current session if current session will not exist then it will NOT create new session.