JAVA NIO – FileLock

Locking on File introduced with java.nio package that implemented by FileChannel. A FileLock is two types exclusive and shared. A shared lock allows other concurrently running program to acquire overlapping shared Lock. An Exclusive lock doesn’t allow other program to acquire overlapping lock.

Lock ideally supports shared Lock but it depends OS if OS doesn’t support share lock then it will act as exclusive locking. Locking applied on File not per channel or thread means if channel obtained the exclusive lock then other JVM’ channel will be block till first thread channel resume the lock.


Locks are associated with a file, not with individual file handles or channels Locking applied on File not per channel or thread means if channel obtained the lock before processing the file then other JVM’ channel will be block till first thread channel resume the lock. Since Lock is on File therefore it is not advisable to use lock on a single JVM.

Below is FileLock API in FileChannel class











public abstract class FileChannel extends AbstractInterruptibleChannel implements SeekableByteChannel,
      GatheringByteChannel, ScatteringByteChannel {
public abstract FileLock lock(long position, long size, boolean shared) throws IOException;
   public final FileLock lock() throws IOException {
       return lock(0L, Long.MAX_VALUE, false);
   public abstract FileLock tryLock(long position, long size, boolean shared) throws IOException;
   public final FileLock tryLock() throws IOException {
       return tryLock(0L, Long.MAX_VALUE, false);


The FileLock (long position, long size, boolean shared) acquire lock on specified part of a file. The region of file specified by beginning position and size whereas last argument specified if lock is shared lock (value True) of exclusive (value False). To obtain the shared lock, you need to open file with read permission whereas write permission require exclusive lock.

We can use lock () method to acquire lock on whole file not the specified area on file. File can grow therefore we need to specify the size while obtaining the lock.

Method tryLock on specified area or on full file doesn’t block/hold while acquiring a lock means it immediately return value without going to wait to acquire lock. If other process already acquired lock for specific file then it will immediate return null.





FileLock API specified as below.

public abstract class FileLock {
  public final FileChannel channel( )
   public final long position( )
   public final long size( )
   public final boolean isShared( )
   public final boolean overlaps (long position, long size)
   public abstract boolean isValid( );
   public abstract void release( ) throws IOException;

The FileLock encapsulates specific region, which is acquired by FileChannel. FileLock associate with specific FileChannel instance and FileLock keep the reference of FileChannel that could be determining by channel () method in FileLock.

FileLock lifecycle will start when lock method or tryLock invoke from FileChannel and end when release () method called. It FileLock also invalid if JVM shutdown or associated channel closed.

isShared() method return whether lock is shared or exclusive. If shared lock is not supported by operating system then this method always return false.

FileLock objects are thread-safe; multiple threads may access a lock object concurrently.

Finally, overlaps(long position, long size) return if lock overlap the given block range or not.

FileLock object associated with an underlying file which occurred deadlock if you don’t release the lock hence it is advisable to always release lock as mentioned below



FileLock lock = fileChannel.lock( )
try {
} catch (IOException) [
} finally {
   lock.release( )

JAVA NIO – Memory-Mapped File

In Java’s earlier version, It uses FileSystem conventional API to access system file. Behind the scene JVM makes read () and write () system call to transfer data from OS kernel to JVM. JVM utilize it memory space to load and process file that causes trouble on large data file processes. File page convert to JVM system before processing the file data because OS handle file in page but JVM uses byte stream that is not compatible with page. In JDK version 1.4 and above Java provides MappedByteBuffer which help to establish a virtual memory mapping from JVM space to filesystem pages. This removes the overhead of transferring and coping the file’s content from OS kernel space to JVM space. OS uses Virtual Memory to cache the file in outside of Kernel space that could be sharable with other non-kernel process. Java maps the File pages to MappedByteBuffer directly and process these file without loading into JVM.

Belo diagram show how JVM mapped the file with MappedByteBuffer and process the file without loading the file in JVM.


MappedByteBuffer directly map with open file in Virtual Memory by using map method in FileChannel. The MappedByteBuffer object work like buffer but its data stored in a file on Virtual Memory. The get() method on MappedByteBuffer fetch the data from file which will represent current file data stored inside disk. In similar way put () method update the content directly on disk and modified content will be visible to other readers of the file. Processing file through MappedByteBuffer has big advantage because it doesn’t make any system call to read/write on file that improve the latency. Apart from that File in Virtual Memory cache the memory pages that will directly access by MappedByteBuffer and doesn’t consumes JVM space. The only drawback is the it throw page fault if requested page is not in Memory.

Below some of the key benefits of MappedByteBuffer:

  1. The JVM directly process on Virtual Memory hence it will avoid system read () and write() call.
  2. JVM doesn’t load file in its memory besides it uses Virtual Memory that bring the ability to process large data in efficient manner.
  3. OS mostly take care of reading and writing from shared VM without using JVM
  4. It could be used more than one process based on locking provided by OS. We will be discussing locking in later.
  5. This also provides ability map a region or part of file.
  6. The file data always mapped with disk file data without using buffer transfer.


Note: JVM invokes the shared VM, page fault generated that push the file data from OS to shared memory. The other benefit of memory mapping is that operating system automatically manages VM space.


public abstract class FileChannel
   extends AbstractInterruptibleChannel
   implements SeekableByteChannel, GatheringByteChannel, ScatteringByteChannel
   public abstract MappedByteBuffer map(MapMode mode,
           long position, long size) throws IOException;
   public static class MapMode {
   public static final MapMode READ_ONLY
   public static final MapMode READ_WRITE
   public static final MapMode PRIVATE

As per above code map () method on FileChannel pass the arguments as mode, position and size and return MappedByteBuffer for part of file. We can also map entire file by using as below

buffer =, 0, fileChannel.size());

If you increase the size larger than file size then file will also become large to match the size of MappedByteBuffer in write mode but throw IOException in read mode because file can not modified in read mode. There are three type of mapping mode in map() method

  • READ_ONLY: Read only
  • READ_WRITE: Read and update the file
  • PRIVATE: Change in MappedByteBuffer will not reflect to File.

MappedByteBuffer will also not be visible to other programs that have mapped the same file; instead, they will cause private copies of the modified portions of the buffer to be created.

Map()method will throw NonWritableChannelException if it try to write on MapMode.READ_WRITE mode. NonReadableChannelException will be thrown if you request read on channel not open on read mode.


Below sample code show how to use MappedByteBuffer

public class MemoryMappedSample {
  public static void main(String[] args) throws Exception {
       int count = 10;
       RandomAccessFile memoryMappedFile = new RandomAccessFile("bigFile.txt", "rw");
       MappedByteBuffer out = memoryMappedFile.getChannel().map(FileChannel.MapMode.READ_WRITE, 0, count);
       for (int i = 0; i < count; i++) {
           out.put((byte) 'A');
       for (int i = 0; i < count; i++) {
           System.out.print((char) out.get(i));

JAVA NIO – Channel

A channel uses ByteBuffer to transfer I/O from source buffers to target buffers. We can pass the data into Buffer, which send to Channel or Channel push the data into Buffer back.

Channels provide direct connection with IO to transport data from OS ByteBuffer and File or Sockets. Channel uses buffers to send and receive data, which is compatible with OS ByteBuffer and minimize the overhead to access the OS’s filesystem.

A channel provides open connection to I/O such as network socket, file etc. to read and write operations. Channel could not directly open but could be open by calling open method on RandomAccessFile, FileInputStream, or FileOutputStream object. A Channel interface provides close method and once channel closed it could not able to reopen and throws exception ClosedChannelException.

Below is the Channel interface

public interface Channel extends Closeable {
public boolean isOpen();
public void close() throws IOException;

Channel interface depends upon operating system native calls provide by OS provider. It provides isOpen () to check is channel is open and close () to close the open channel,

Below diagram shows overall package diagram

JAVA NIO Channel

The InterruptibleChannel interface is marker that could be asynchronously closed and interrupted, means if a thread is blocked in an I/O operation on as interruptible channel then thread may invoke close method asynchronously.

WritableByteChannel interface that extends Channel interface provide write (ByteBuffer src) method to write a sequence of bytes to this channel from the given buffer.

RedableByteChannel interface have read (ByteBuffer) method that reads sequence of bytes from channel into the buffer passed as argument. Only one thread can invoke read operation and if other thread initiate that time it will block until the first operation is complete.

The NIO provide concretes interfaces with various implementation in SPI package which could be change by different provider. SelectableChannel uses Selector to multiplex ByteBuffer. Package java.nio.channels.spi provide implementation of various channel. For instance AbstractInterruptibleChannel and AbstractSelectableChannel, provide the methods needed by channel implementations that are interruptible or selectable, respectively.

A Channel handle communicates with I/O in both direction similar to InputStream and OutputStream. It is capable to handle concurrent write & read, means it doesn’t block I/O to be read or write.

Channels Creations

There are two types of channel File and Sockets. Sockets channels are three types SocketChannel, ServerSocketChannel and DatagramChannel. Channel could be created in several ways for instance socket channels have factory method to create new socket channels whereas FileChannel could be created by calling getChannel () in IO Stream / RandomAccessFile.

SocketChannel socketchannel = );
socketchannel.connect (new InetSocketAddress ("host", someport));
ServerSocketChannel channel = );
ssc.socket( ).bind (new InetSocketAddress (somelocalport));
DatagramChannel channel = );
RandomAccessFile randaccfile = new RandomAccessFile ("file", "r");
FileChannel channel = randaccfile.getChannel( );

Channels could be unidirectional or bidirectional for instance if class implements ReadableByteChannel and WritableByteChannel both then this class will be bidirectional channel but if class implements any one of them then it will be unidirectional channel.


Selector provides capabilities to process single IO operation across multiple buffers. Selector class uses multiplex to merge multiple stream into single stream and DE-multiplex to separate single stream to multiple stream. For example write data is gathered from multiple buffers and sent to Channel.

Selector operation intern call OS native call to fill or drain data directly without directly copying to buffer.

public interface ScatteringByteChannel extends ReadableByteChannel {
public long read(ByteBuffer[] dsts, int offset, int length) throws IOException;
public long read(ByteBuffer[] dsts) throws IOException;

public interface GatheringByteChannel extends WritableByteChannel {
public long write(ByteBuffer[] srcs) throws IOException;
public interface WritableByteChannel extends Channel {
public int write(ByteBuffer src) throws IOException;


JAVA NIO – Buffer

A Buffer is abstract class of java.nio, which contains fixed amount of data. It can store data and later retrieve those data. Buffer has key three properties:

  • Capacity: A buffer’s capacity is the number of elements it contains. It is constant number that doesn’t change
  • Limit: A buffer limits is the index of the first element that should not be read or written. It always less than buffer’s capacity.
  • Position: A buffer position is the index of next element to be read from the buffer.

There is one subclass of this class for each non-boolean primitive type e.g. CharBuffer, IntBuffer etc. Buffer is abstract class that extended by non-Boolean primitive that provide common behavior across the various Buffers as shown below.


A buffer is a linear, finite sequence of elements of a specific primitive type wrapped inside an object. It constitutes date content and information about the data into single object. Data may transfer in to or out of the buffer by the I/O operations by a channel at the specified position. The I/O operation can read and write at the current position and then increment the position by the number of elements transferred. Buffer throws BufferUnderflowException and BufferOverflowException if position exceed while get operation or put operation respectively. The position field of Buffer specified the position to retrieve or insert the data element inside Buffer. Limit fields of Buffer indicates the end of the buffer which can be set using below operation

public final Buffer limit(int newLimit)

We can also drain the buffer by using flip method as below operation

public final Buffer flip()

Flip method set the limit to the current position and position to 0.The rewind () method is similar to flip () but does not affect the limit. It only sets the position back to 0. You can use rewind () to go back and reread the data in a buffer that has already been flipped.

Byte Buffers:

ByteBuffer is similar to OS ByteBuffer that could be mapped to OS’s ByteBuffer without any translation. ByteBuffer uses Byte core unit to read and write IO data, which is more significant, compare to other primitive data type buffers.

Byte buffers can be created either by allocation, which allocates space for the buffer’s content, or by wrapping an existing byte array into a buffer.

ByteBuffer are two type Direct Buffer and Indirect Buffer.

Direct & Indirect Buffers

ByteBuffer are two types Direct Buffer and Indirect Buffers. The key difference between direct buffer and indirect buffer is that direct buffer could directly access native IO calls whereas indirect buffers could not. Direct buffer access file data directly by using native I/O operation to fill or drain byte buffer. Direct buffer is memory consuming but other side it provided most efficient I/O mechanism. It doesn’t copy the buffer’s content to an intermediate buffer or vice versa.

Indirect buffer could also be used to pass the data but it could not directly uses native I/O operation upon it. Indirect buffer indirectly uses temporary direct buffer to access file IO data.

A direct buffer could be created by allocateDirect factory method, which is more expensive, and therefore it is advisable to use direct buffers only when they yield a measureable gain in program performance.

Whether a byte buffer is direct or non-direct may be determined by invoking its isDirect () method. This method is provided so that explicit buffer management can be done in performance-critical code

JAVA NIO – Introduction

Operating System allocates memory to JVM to process its task. In old JDK (>1.4), JVM uses FileSystem API to access file from hard disk which is quite burden to JVM because there is no direct reference between JVM and File inside hard disk. JVM uses Operating System system calls to access file. Operating System stores files into large ByteBuffer, which is quite large compare to byte stream used by JVM. JVM uses extra efforts to convert ByteBuffer to byte stream and vice versa.

So there were two key challenges in existing old JDK

  • It could not access file directly from disk
  • It has to do extra efforts to convert files data to byte stream

Following are the key steps to access Files

  1. Operating System allocate memory to JVM
  2. Client invoke FileSystem to access specific file from OS
  3. JVM make OS system call to access to File data
  4. JVM get OS’s data as ByteBuffer and converts it into Byte Stream

For large file OS uses Virtual Memory to store data outside of RAM. The benefit of Virtual Memory is that it is sharable across multiple processes and hence VM could be accesses by OS and JVM both. From transferring data from OS to VM could be quite fast by using DMA (Direct Memory Access) whereas transferring data from VM to JVM is slow because JVM does extra efforts to break large data buffer to byte stream.

JAVA FileSystem: Java uses FileSystem API to access physical storage inside system. When client try to access a particular file via FileSystem, FileSystem identify storage location and load those disk stores into memory.

File’s data stores into multiple pages and page contain group of block. Kernel establishes mapping between memory pages and filesystem pages.

The Virtual memory read paging content from disk and uses page fault to synchronize the file data to Virtual Memory. Once pageins completed FileSystem read the file contents and its Meta information


JAVA NIO that introduce JDK 1.4 and keep enhancing on newer version improve the I/O operations. It provides new type of buffers such as ByteBuffer, CharBuffer, and IntBuffer etc. that reduce the overhead during transferring data from OS to JVM. Java NIO could be able to map directly from VM to JVM bye using new ByteBuffer. JAVA ByteBuffer is same as OS Byte Buffer that’s why it could be easily mapped from OS Byte Buffer to JVM Byte Buffer so less overhead on data conversion from OS to JVM.


As per above diagram if OS uses VM and JVM use newly NIO interface, it enhances the performance while processing file especially large file. We will also discuss later there are another MappedByteBuffer which have capabilities to directly process the file in VM without transferring data from VM to JVM.

Java Interview Reference Guide – Concurrent Framework

The Java Concurrent framework provide a powerful, extensible framework of high-performance threading utilities such as thread pools, Executors, synchronize, concurrent collection, locks, atomic variables and Fork/Join.

Concurrent framework consists below packages:

Java.util.concurrent: It is main package, which provides common libraries such as concurrent collection (ConcurrentHashMap.), ForkJoin, Executors, and Semaphore etc. to build concurrent application.

Java.util.concurrent.atomic: This subclass provide thread safe variable without synchronized key. It uses CAS (compare-and-set) instruction support to provide thread safe.

Java.util.concurrent.locks: This subclass contains low-level utility types for locking and waiting for conditions without using synchronization and monitors. Java.util.concurrent.locks.ReentrantLock implements Lock interface is more efficient over traditional synchronized based monitor lock mechanisms.

Continue reading

Java Interview Reference Guide – Synchronization


The synchronized modifier is used to control access to critical code in multi-threaded program. The synchronized keyword is one of the tools that make your code thread safe. The “Synchronized” modifier in Java prevents concurrent access code block or methods by multiple threads. Synchronized force threads to obtain a lock before entering the method and release the lock after completing the method. It ensures that only one thread can execute the method at a time.

If we make method or block as synchronized then it will not allow more than one invocations on synchronized method on the same object. If one method invoke synchronized method other thread block until the first thread complete the method execution.

First method acquires the lock of that object before entering the synchronized method of the same object and releases it to acquire by other threads. Synchronize method use happens-before relationship, which guarantees that changes to the state of object are visible to all threads

When you mark a block of code as synchronized you use an object as a parameter. When an executing thread comes to such a block of code, it has to first wait until there is no other executing thread in a synchronized block on that same object. However a thread could enter the block of synchronized method other object. But non-synchronized method in same object can access without checking lock.

if you synchronize on a static method you will synchronize on the class (object) and not on an instance (object). That means while execution of a static method the whole class is blocked. So other static synchronized methods are also blocked

1) When a thread has entered a synchronized instance method then no other thread can enter any of synchronized instance methods of the same instance

2) When a thread entered a synchronized static method then no other thread can enter any of synchronized static methods of the same class

Note: No link between synchronized static methods and non static methods that means Static synchronize and non-static synchronize method can run concurrently unless your non-static method must explicitly synchronize on the class itself (ie, synchronized (MyClass.class) {…}

Note: Constructor of class cannot be synchronized.

Monitor or Intrinsic Lock

 Intrinsic locks enforce restriction on access to an object’s state and establish happens-before relationships.

Every object has an intrinsic lock and a thread has to acquire the object’s intrinsic lock before accessing them and release it when it’s done. Other thread cannot access the object’s state till thread owns its intrinsic lock. It ensure that state change done by a thread will be visible to other thread which synchronize on the same monitor.

After thread release lock which effect of flushing the cache to main memory so that object’s state change will be visible to other thread and that is called happens-before relationship.

The synchronized and volatile constructs, as well as the Thread.start () and Thread.join() methods, can form happens-before relationships.

The locks acquired by synchronized statements are the same as the locks that are acquired implicitly by synchronized methods. A single thread may acquire a lock more than once.

Acquiring the lock associated with an object doesn’t prevent other threads for accessing fields of the object or invoking un-synchronized methods.

The synchronized statement attempts to seek lock of object and the body of synchronized statements executed once it acquire lock of that object and unlock after completing the synchronized statements.

If the method is member or instance of object then it will lock instance for which it was invoked. If the method is static, it locks the monitor associated with the Class object that represents the class in which the method is defined. Synchronize method control by its property-SYNCHRONIZED flag, which is check by method invocation instructions.

Atomic Variable

If we consider int i++ it contains combination of multiple operation e.g. it reads value from memory, increment and puts write back to the memory. This operation is fine for single thread operation but might give wrong answer in multi-thread environment. It also have race issue means multiple thread can read the value at the same time.

Atomic access ensures that action happens all at once. An atomic action occurs completely or doesn’t occur at all.

There are actions you can specify that are atomic:

  1. Reads and writes are atomic for reference variables and for most primitive variables (all types except long and double).
  2. Reads and writes are atomic for all variables declared volatile (including long and double variables).

The java.util.concurrent.atomic package defines classes that support atomic operations on single variables. All classes have get and set methods that work like reads and writes on volatile variables. That means, a set has a happens-before relationship with any subsequent get on the same variable. The atomic compareAndSet method also has these memory consistency features, as do the simple atomic arithmetic methods that apply to integer atomic variables .

In java 5.0 java.util.concurrent.atomic package define classes that supports atomic operation on single operation. The JVM compiles these classes with the better operations provided by the hardware machine, CAS (Compare and Set).

  • AtomicInteger
  • AtomicLong
  • AtomicBoolean
  • AtomicReference

All classes have get and set methods that work like reads and writes on volatile variables. That is, a set has a happens-before relationship with any subsequent get on the same variable. The atomic compareAndSet method also has these memory consistency features, as do the simple atomic arithmetic methods that apply to integer atomic variables

Volatile variable

Only variable may be volatile. Such variable might be modified asynchronously so the compiler takes special precaution

The volatile modifier guarantees that any thread that reads a field will see the most recently written value

Using volatile variables reduces the risk of memory consistency errors, because any write to a volatile variable are always visible to other threads. What’s more, it also means that when a thread reads a volatile variable, it sees not just the latest change to the volatile, but also the side effects of the code that led up the change.

In a multi thread environment object make their own copy of object in threads local cache except volatile variable that means volatile will have only one copy in heap which will updated by thread and immediately reflect to other Thread. There is no flush of local’s thread cache memory after completing the process.

Volatile fixed visibility issue but bring race condition and it will not lock to wait to complete the process for example :

Volatile int i=0

i +=5 invoking by two simultaneously thread give result 5 or 10 but it guarantee to see immediate changes.

Use of volatile: One common example for using volatile is to use a volatile boolean variable as a flag to terminate a thread.


Difference between static and volatile variable

Declaring static variable means there will be only copy associated with class it doesn’t matter how many object get created for that class. The static variable will be accessible even with no Objects created at all. Thread may have locally cached values of it.

This means that if two threads update a variable of the same Object concurrently, and the variable is not declared volatile, there could be a case in which one of the threads has in cache an old value. Even if you access a static value through multiple threads, each thread can have its local cached copy!

But a volatile variable will keep only one copy in memory and shared across the threads.

 Difference between Volatile and Synchronize:

So where volatile only synchronizes the value of one variable between thread memories and “main” memory, synchronized synchronizes the value of all variables between thread memory and “main” memory, and locks and releases a monitor to boot. Clearly synchronized is likely to have more overhead than volatile.

A volatile variable is not allowed to have a local copy of a variable that is different from the value currently held in “main” memory. Effectively, a variable declared volatile must have it’s data synchronized across all threads, so that whenever you access or update the variable in any thread, all other threads immediately see the same value.

Lock Objects

Lock object behave same as implicit locks, which is used by synchronized code. As with implicit locks, only one thread can own a Lock object at a time. Lock objects also support a wait/notify mechanism, through their associated condition object.

The biggest advantage of Lock objects over implicit locks is their ability to back out of an attempt to acquire a lock. The tryLock() method backs out if the lock is not available immediately or before a timeout expires (if specified). The lockInterruptibly() method backs out if another threads sends an interrupt before the lock is acquired

 Java garbage collector

Each time an object is created in Java, it goes into the area of memory known as heap. The Java heap is called the garbage collectable heap. The garbage collection cannot be forced. The garbage collector runs in low memory situations. When it runs, it releases the memory allocated by an unreachable object. The garbage collector runs on a low priority daemon (i.e. background) thread. You can nicely ask the garbage collector to collect garbage by calling System.gc() but you can’t force it.

How to write a Deadloack

In some cases in multi thread environment deadlock situation occured means two or more thread are blocked forever, waiting for each other.
Below sample code is an deadlock scenarios:

public class DeadlockSample {
private final Object obj1 = new Object();
private final Object obj2 = new Object();

public static void main(String[] args) {
DeadlockSample test = new DeadlockSample();

private void testDeadlock() {
Thread t1 = new Thread(new Runnable() {
public void run() {
Thread t2 = new Thread(new Runnable() {
public void run() {

private void calLock12() {
synchronized (obj1) {
synchronized (obj2) {
private void calLock21() {
synchronized (obj2) {
synchronized (obj1) {
private void sleep() {
try {
} catch (InterruptedException e) {

Explain types of references in Java?

java.lang.ref package can be used to declare soft, weak and phantom references

  • Garbage Collector won’t remove a strong reference.
  •  A soft reference will only get removed if memory is low. So it is useful for implementing caches while avoiding memory leaks.
  •  A weak reference will get removed on the next garbage collection cycle.  Can be used for implementing canonical maps. The java.util.WeakHashMap implements a HashMap with keys held by weak references.

A phantom reference will be finalized but the memory will not be reclaimed. Can be useful when you want to be notified that an object is about to be collected.

Effective Java™