Interrupting a Thread in Java

I have been working on a priority change request which was supposed to be fixed by end of business hour today. Today morning, I was totally engrossed into it when my boss interrupted me to convey that CR has been deferred. Gosh! what a relief it was. 

An interrupt is basically an indication to a thread that it should do something else instead of whatever it is doing right now. Something else is subjective here;  thread could abort or terminate the task, ignore the interrupt request after acknowledging it or it could even ignore it altogether as if nothing happened.
Usually interrupt mechanism works between two threads. One thread raises interrupt for other thread. Once interrupt is received by the other thread, it can act as per its wish. Thread can also interrupt itself.

Interrupting a Thread

Interrupting a thread is quite trivial. Just get a handle to thread and call interrupt method on it. Done!

              t.interrupt();

Below class demonstrates how to call interrupt on a thread. Main thread creates a new thread which keeps on incrementing and printing a counter.

 public class InterruptDemo1 {   
    static int counter = 0 ;   
    public static void main(String[] args) {   
       Runnable task = new Runnable(){   
         public void run(){   
            while(true){   
              System.out.println(" val :"+ counter++);                
            }   
         }   
       };   
       Thread secondThread = new Thread(task);   
       secondThread.start();     
       secondThread.interrupt();      
    }   
  }   

If you run above program, it will go on and on, printing the incremented value (couldn't see it stopping for 10 minutes on my machine).

In the last line, main thread interrupts secondThread. But it is not making any difference to the execution of the program. Is it all cool?

Handling Interrupt

As far as raising interrupt is concerned, above class demonstrates it perfectly. The problem is actually with second thread which is not handling the raised interrupt. And that's the reason why you see uninterrupted value on your console. So even if an interrupt is raised the thread can chose to ignore it.

In modified class below, interrupt gets handled by the task/thread.

 public class InterruptDemo2 {  
      static int counter = 0 ;  
      public static void main(String[] args) {  
           Runnable task = new Runnable(){  
                public void run(){  
                     while(true){  
                          System.out.println(" val :"+ counter++);  
                          if(Thread.interrupted())  //Thread refers to current thread
                               return;  
                     }  
                }  
           };  
           Thread secondThread = new Thread(task);  
           secondThread.start();  
           secondThread.interrupt();  
      }  
 }  

Now interrupt is getting handled in the second thread (run above program to confirm the same).

Details on Interrupt methods of Thread

 package java.lang;  
 public class Thread implements Runnable{  
      public void interrupt(){..}  
      public boolean isInterrupted(){..}  
      public static boolean interrupted(){..}  
   ...  
 }  

As discussed in previous examples, interrupt() method can be used to interrupt a thread. Thread maintains this state through a boolean interrupted status flag. This flag can be used to check the status of interruption by calling isInterrupted() method. And interrupted() method returns the status as well as clears the value. This is the only way to clear the interrupt status flag (i.e. sets it to false). Just be careful in the usage of this method though. Your task/thread might eat the interrupt. Best approach is, either handle interruption ( by exiting or throwing InterruptedException) or restore the interruption status by calling interrupt() again.

Blocking methods like Thread.sleep and Object.wait can also detect interrupt on a thread. These methods respond to interrupt by clearing the status flag and also by throwing InterruptedException.

Stopping a Thread

Stopping a task (and thread) safely and quickly is not easy. We need a cooperative mechanism to make sure that stopping the thread doesn't leave it in an inconsistent state. This was the reason why Java designers deprecated stop and suspend method from Thread class.

One of the most wildly used approach is, keep a thread-safe flag to notify to the thread that it can cancel the task. But this is not a reliable approach, task might not check the cancelled flag if it's making blocking API call.

          volatile boolean cancelled = false;    //class attribute
           //task component
            if(!cancelled){
                  //blocking api call
            }else{
               return;
            }

Interruption mechanism discussed in this post, is safest and most sensible approach to stop a thread. So you can design your task in such a way that when it receives interrupt, it can come out of task gracefully.

--happy interruption!

Atomic operations in Java

Before jumping to the topic;  let's first understand the keyword, Atom. Wikipedia defines Atom as something that can not be divided further (i.e. uncuttable or indivisible).

Java and other modern programming languages use the term atomicity for operations/methods, which gets executed as one unit. An atomic operation is either fully done or not done, there is no intermediate state.  

       
       public class SharedStorage{
             private int a = 5;

             int increment(){

                    a++

               }
        }

Method, increment() in above class is one of the most trivial operations possible in Java (or any language). Is it atomic ? 

No, it is NOT.
The method is NOT indivisible as it consists of sub-operations (read the number and then increment it by one). So at any given time, it could be in either state (i.e. reading value or incrementing it by one). 

Importance of Atomic Operations

As we saw, even one of the simplest method is not atomic. The legitimate question is, is it really important?

If your application has a single thread of execution, it doesn't make any difference. Single threaded applications are sequential and they execute in the given order. So practically, the question of atomicity doesn't arise. 

Atomicity starts playing a role only if there is a possibility that an operation which modifies some shared data (or state) can be called by multiple threads at the same time. Assume that, two threads call increment() method of above class at the same time. What would be the value of a after completion of both threads? 

Final value of a could be 6 or 7. Let's understand this -
t1.start();
t2.start();

Even if thread, t2 starts after thread, t1 in your source code; JVM doesn't guarantee the same behavior at the time of execution. Sequential executions don't hold good anymore here. 

Java uses shared memory for communication between two threads. At the time of execution, both threads could read value of a at same time, hence, the incremented value will be 6. Or at the different time or on a different platform it a could have value as 7. This is a matter of concern!

In this post, I will be discussing how Java helps you to make operations atomic and also about some of the inbuilt atomic classes.

Important learning is; atomicity arises only when two or more threads can access a shared resource. 

Atomic Operations

We have seen earlier, even trivial operations like increment are not atomic in Java. Does it mean that no operation is atomic? Certainly NOT. Java ensures that some basic operations are always atomic:

• Read and write for primitive variables (except long and double)
• Read and write for reference variables 
• Read and write for any variable (including long and double) and references declared as volatile

Java 7 specification clearly states that read or write to a non-volatile long or double is treated as two separate actions one for each 32 bit half.  Thus read and write on long/double are not atomic. Also, restriction of 32 bit is not applicable for references. So read and write on all references are atomic, irrespective of the size. 

Java also provides a second mechanism to make any shared attribute atomic by declaring it volatile [Java 7 Spec]. If a field is declared as volatile Java Memory Model ensures that all threads see a consistent value for the variable. 

Let's consider non-trivial operations which are commonplace in any normal application. We have discussed already, the increment method in SharedStorage class is NOT atomic.
How do you handle such operations in a concurrent environment?
How can we ensure that even if multiple threads invoke the methods, it remains in a consistent state?

Java provides another way to make an operation atomic.

 public class SharedStorage {  
      private int counter = 5;  //need to make it volatile
      public int getCounter(){  
           return counter;  
      }  
      public synchronized void increment(){  
           counter++;  
      }  
 }  

If you declare any method as synchronized, it means only one thread can invoke it at a time. This makes the operation atomic implicitly ( and makes thread-safe as well).

There is still a problem with above class ?
Assume that thread, t1 calls increment method, and in mean time another thread, t2 calls get method to read the value of counter. Which value will be read by thread t2 ; 5 or 6 ? Answer to this question is still uncertain; you can get any value.

Synchronizing increment method has solved one part of the problem. But it has not made the overall state of program consistent in a concurrent environment.

There are two alternatives to fix this :

1. Either declare counter attribute as volatile. OR
2. Synchronize the getCounter() method. 

You might question, why do we need to declare counter as volatile? We discussed earlier that read on primitives (except long and double) is atomic.
getCounter() method would have been atomic in the absence of synchronized increment method. We are forced to declare counter as volatile only due to synchronized increment method. To make a class fully thread safe all operations which are reading or modifying the state needs to be synchronized.

Java Provided Atomic APIs

Java has rich set of API for making life easier for programmers. So if you just need a atomic counter variable, you can use inbuilt class, instead of creating a new class altogether.
The java.util.concurrent.atomic package provides such classes. You can use AtomicInteger, AtomicLong etc as per your requirement instead of doing it from scratch.

Thread-local variable in Java

Instances of a class maintain their own state through non-static data attributes. So, if you create 100 instances of Student class, they all have their own copy of name, age etc. Like this, life continues for objects and it's all cool!

Along with objects, Java has another level of abstraction (more lower level than objects); threads. The obvious question is, how are you going to manage state among multiple threads?  

In below code snippet, local variable, state can't keep value specific to each thread.

 sampleMethod(){  
  String state = "default";  
  Thread t1 = new Thread(){  };  //thread 1  
  Thread t2 = new Thread(){  };  //thread 2
 }  

Literally,  thread-local means, something which is local to a thread. One way to keep a variable local to a thread is;  inherit Thread class and add state.  And create unique objects for each thread. This solution can only work in trivial situations; and in some cases it might not be even feasible. Definitely there is a need for a cleaner approach.

 public class MyThread extends Thread{  
     String state;  
     public void run() { ... }   
 }   

java.lang.ThreadLocal<T> class

Java provides a specific class (since version 1.2) named as ThreadLocal, which allows you to associate a per-thread value with a value-holding object. This object provides get and set accessor methods that maintain a separate copy of the value for each thread that uses it. Below is a simplest example to illustrate the point. 

1:  public class ThreadLocalDemo {  
2:       private static ThreadLocal<String> tl = new ThreadLocal<String>();  
3:       public static void main(String[] args) {  
4:            tl.set("Main Thread");  
5:            Runnable r = new Runnable(){  
6:                 public void run(){  
7:                      tl.set("Sub Thread");  
8:                      System.out.println("Thread Local in Sub Thread :"+ tl.get());  
9:                      tl.remove();  
10:                 }                 
11:            };  
12:            System.out.println("Thread Local in Main :"+ tl.get());  
13:            Thread t = new Thread(r);  
14:            t.start();  
15:            tl.remove();  
16:       }  
17:  }  

Output:

Thread Local in Main : Main Thread

Thread Local in Sub Thread :Sub Thread

Note that, in the above class there are two threads (JVM runs this program in a separate thread and calls the main method and then there is a second thread (as t) created by the main method). The output clearly confirms that values stored in ThreadLocal object by two threads are preserved without any external synchronization. So, irrespective of the number of threads, ThreadLocal will create and maintain one unique storage for each thread. Method, get is used to return most recent value passed to set method from the currently executing thread. Conceptually, ThreadLocal can be visualized as a Map which stores value for each thread. (i.e. ThreadLocal<T>  equivalent to  Map<Thread, T>).

Let's go through a non-trivial example. Below is a ThreadLocalHolder class, which creates five threads for displaying thread-local behavior. Inner class, MyThreadLocal manages all methods of ThreadLocal class. Method, initialValue() is used to set an initial value.

1:  import java.util.Random;  
2:  public class ThreadLocalHolder implements Runnable {  
3:       private static Random rand = new Random(21);  
4:       class MyThreadLocal {  
5:            private ThreadLocal<Integer> tl = new ThreadLocal<Integer>() {  
6:                 protected Integer initialValue() {  
7:                      return rand.nextInt(100);  
8:                 }  
9:            };  
10:            public Integer getValue() {  
11:                 return tl.get();  
12:            }  
13:            public void setValue(Integer v) {  
14:                 tl.set(v);  
15:            }  
16:            public void remove() {  
17:                 tl.remove();  
18:            }  
19:       }  
20:       @Override  
21:       public void run() {  
22:            MyThreadLocal tlc = new MyThreadLocal();  
23:            tlc.setValue(rand.nextInt(1000));  
24:            System.out.println(" Val for thread : " + tlc.getValue());  
25:            // task logic  
26:            tlc.remove();  
27:       }  
28:       public static void main(String[] args) throws InterruptedException {  
29:            ThreadLocalHolder tlh = new ThreadLocalHolder();  
30:            for (int i = 0; i < 5; i++) {  
31:                 Thread t = new Thread(tlh);  
32:                 t.start();  
33:            }  
34:       }  
35:  }  

Output:
 Val for thread :  144
 Val for thread :  724
 Val for thread :  320
 Val for thread :  627
 Val for thread :  478

Final Note

You should be very careful in using ThreadLocal class. The value stored in this object stays as long as the thread is active.
So it could create an issue if your application is running in an Application server thread? In such case, the object stored in ThreadLocal will never get reclaimed as long as your application is up and running. 

--

Time to call it a post..do drop your feedback/comments. 

Tricky aspects of Anonymous Classes in Java

I have discussed briefly about anonymous classes in my earlier Inner class post. Some of the aspects of Anonymous classes are confusing which require more elaborate explanation. And few aspects are not well known to most of the programmers. So, I am revisiting these aspects of Anonymous class in detail here.

[Brush up Inner Class and Anonymous class basics - here]
[Java 7 Specification of Anonymous class - here]

As a refresher; Anonymous classes are declared inline inside another class, and hence they are inner as well. So we can call them as Anonymous class or Anonymous Inner class. Also, Anonymous class can never be static and abstract and they are implicitly final [Java Specification]. 

Compact and Efficient Code

If you use Anonymous classes properly, you can reduce the number of lines of code. Check out below example. It shows three styles of creating an instance of thread using Anonymous class.

 public class AnonymousSample {  
      public static void main(String[] args) {  
   
           // first approach  
           Runnable r = new Runnable() {  
                public void run() {  
                     System.out.println("run !");  
                }  
           };  
           Thread t = new Thread(r);  
           t.start();  
   
           // second approach  
           Thread tt = new Thread(new Runnable() {  
                public void run() {  
                     System.out.println("run !");  
                }  
           });  
           tt.start();  
   
           // third approach  
           new Thread() {  
                public void run() {  
                     System.out.println("run !");  
                }  
           }.start();  
      }  
 }  

All the above approaches achieve the same thing, but clearly, the third approach is much more compact and cleaner way. 

Can't have an explicit constructor

Yes, Anonymous class can't have a constructor.

There is a workaround, though. You can declare a local final variable and declare an instance initialization block as shown below:

 public class AnonymousConstructor {  
      public static void main(String[] args) {  
           final int attribute;  
           Object obj = new Object() {  
                {  
                     attribute = 20;  
                     System.out.println("arg = " + attribute);  
                     method();  
                }  
   
                public void method() {  
                     System.out.println("inside method");  
                }  
           };  
      }  
 }  

But, there is still a problem.

The variable attribute can't be modified inside the inner class (compiler forces you to make it final). So, we haven't been able to truly initialize/construct the variable inside initialization block. 

But there is a hack for it as well!
Java treats final objects and final primitives differently.

When an object is declared as final, its reference can't be changed but you can change the value contained in it. In below example, I have created a dummy array to contain the primitive value. (Remember that in Java array is also an object).

 public class AnonymousConstructor {  
      public static void main(String[] args) {  
           final int attribute[] = { 10 };  
           Object obj = new Object() {  
                {  
                     attribute[0] = 20;  
                     System.out.println("arg = " + attribute[0]);  
                     method();  
                }  
   
                public void method() {  
                     System.out.println("inside method");  
                }  
           };  
      }  
 }  

Bingo!!! So you can get around the limitation of no explicit constructor.

Double Brace Initialization

This is one of the unknown features of Java. It comes in handy to initialize Collection APIs (List, Set, Map) in a very compact manner. 

 import java.util.ArrayList;  
 import java.util.List;  
   
 public class DoubleBraceInitialization {  
      public static void main(String[] args) {  
           List<String> list = new ArrayList<String>() {  
                {  
                     add("abc");  
                     add("def");  
                }  
           };  
   
           System.out.println(" list is " + list);  
      }  
 }  

Output : list is [abc, def]

Note that, the second brace is instance initialization brace.

Want to read more about it? link

Can't access method outside class

Let's start with a problem directly to stress a point. What will be the output of the below code?

 import java.util.concurrent.Callable;  
 interface Sample{  
   public void sampleMethod();       
 }  
   
 public class AnonymouseMethodInvocation {  
      public static void main(String[] args) {  
           new Sample(){  
                public void sampleMethod(){  
                     System.out.println("inside sample method");  
                }  
                public void method(){  
                     System.out.println("sample method");  
                }  
           }.method();  
          
             
           Callable<String> c = new Callable<String>(){  
                @Override  
                public String call() throws Exception {  
                     return "hello";  
                }            
           };  
      }  
 }  

It won't compile.

Surprised???

The compiler will not allow you to call method m().
When you say

      Sample s = new Sample(){  };

Means that, Create an object of an Anonymous class that's inherited from class Sample.
The reference returned by the new expression is automatically upcast to a Sample reference.

So using superclass reference, you can call method contained in the base class, but not method added in subclass. Here, method m() is added in the anonymous class but sampleMethod() is from the base class itself. So you can call sampleMethod() but not method m().

---
do post your comments/questions below !!!