Java

Exception handling is a critical aspect of Java programming that allows developers to gracefully manage errors and unexpected situations in their code. Java provides a robust mechanism for handling exceptions, which is essential for writing reliable and maintainable applications. In this guide, we’ll explore exception handling in Java in depth, covering various aspects including types of exceptions, try-catch blocks, exception propagation, best practices, and more.

Understanding Exceptions & Exception Handling in Java

Exception

An unexpected, unwanted event that disturbs the normal flow of the program is called an exception. For example, TyredPuncturedException, SleepingException, and FileNotFoundException. It is highly recommended to handle exceptions. The main objective of exception handling is the graceful termination of the program. Exception handling doesn’t mean repairing an exception; rather, it involves providing an alternative way to continue the rest of the program normally. This is the concept of exception handling. For example, if our programming requirement is to read data from a remote file located in London at runtime, and if the London file is not available, our program should not terminate abnormally. Instead, we have to provide some local file to continue the rest of the program normally. This method of defining alternatives is nothing but exception handling.

try {
    // Read data from the remote file located in London
} catch (FileNotFoundException e) {
    // Use a local file and continue the rest of the program normally
}

Runtime Stack Mechanism

For every thread, the JVM will create a runtime stack. Each method call performed by that thread will be stored in the corresponding stack. Each entry in the stack is called a stack frame or activation record. After completing every method call, the corresponding entry is removed from the stack. After completing all method calls, the stack will become empty, and that empty stack will be destroyed by the JVM just before terminating the thread. This is an example of when everything goes well. Next, we will discuss the default exception handling in Java.

Default Exception Handling in Java

Inside a method, if any exception occurs, the method in which it is raised is responsible for creating an exception object by including the following:

1. Name of the exception.
2. Description of the exception.
3. Location at which the exception occurs (Stack Trace).

After creating the exception object, the method hands over that object to the JVM. The JVM checks whether the method contains any exception handling code. If the method doesn’t contain exception handling code, the JVM terminates that method abnormally and removes the corresponding entry from the stack. Then, the JVM identifies the caller method and checks whether the caller method contains handling code or not. If the caller method doesn’t contain handling code, the JVM terminates that caller method also abnormally and removes the corresponding entry from the stack. This process continues until the main method. If the main method also doesn’t contain handling code, the JVM terminates the main method abnormally and removes the corresponding entry from the stack. Then, the JVM hands over the responsibility of exception handling to the default exception handler, which is part of the JVM. The default exception handler prints exception information in the following format and terminates the program abnormally:

----------------------------------------------------------------
Exception in thread "xxx": Name of the exception: Description
                      Stack trace
----------------------------------------------------------------

For example:

class Test {
  public static void main(String[] args) {
    doStuff();
  }
  
  public static void doStuff() {
    doMoreStuff();
  }
  
  public static void doMoreStuff() {
    System.out.println(10 / 0);
  }
}

Runtime Stack:

--------------
doMoreStuff()
--------------
doStuff()
--------------
main()
--------------

Output:

Exception in thread "main": java.lang.ArithmeticException: / by zero
                      at Test.doMoreStuff()
                      at Test.doStuff()
                      at Test.main()

Let’s see one more example,

class Test {
  public static void main(String[] args) {
    doStuff();
    System.out.println(10 / 0);
  }
  
  public static void doStuff() {
    doMoreStuff();
    System.out.println("Hi");
  }
  
  public static void doMoreStuff() {
    System.out.println("Hello");
  }
}

Runtime stack

----------------
----------------
----------------
main()
----------------

Output

Hello
Hi
Exception in thread "main" java.lang.ArithmeticException: / by zero
             at Test.main(Test.java:5)

Note: In a program, if at least one method terminates abnormally, then the program termination is considered abnormal. If all methods terminate normally, then the program termination is considered normal.

Exception Hierarchy

The Throwable class acts as the root for the Java exception hierarchy. The Throwable class defines two child classes:

1. Exception
2. Error

Exception: Most of the time, exceptions are caused by our program and are considered recoverable. For example:

try {
    // Read data from the remote file located in London
} catch (FileNotFoundException e) {
    // Use a local file and continue the rest of the program normally
}

Error: Errors are non-recoverable. For example, if an OutOfMemoryError occurs, being a programmer, we cannot do anything, and the program will be terminated abnormally. System admins or server admins are responsible for increasing heap memory.

Visual Representation

Throwable
│
├── Exception
│   │
│   ├── RuntimeException
│   │   │
│   │   ├── ArithmeticException
│   │   ├── NullPointerException
│   │   ├── ClassCastException
│   │   ├── IndexOutOfBoundsException
│   │   │   │
│   │   │   ├── ArrayIndexOutOfBoundsException
│   │   │   └── StringIndexOutOfBoundsException
│   │   └── IllegalArgumentException
│   │       └── NumberFormatException
│   │
│   ├── IOException
│   │   │
│   │   ├── EOFException
│   │   ├── FileNotFoundException
│   │   └── InterruptedIOException
│   │
│   └── ServletException
│
└── Error
    │
    ├── VirtualMachineError
    │   │
    │   ├── StackOverflowError
    │   └── OutOfMemoryError
    │
    ├── AssertionError
    └── ExceptionInInitializerError

Types of Exceptions

Checked Exceptions

Checked exceptions are the exceptions that are checked at compile-time. These exceptions are subclasses of Exception but not subclasses of RuntimeException. Examples of checked exceptions include IOException, SQLException, and FileNotFoundException. It is mandatory for a method to either handle these exceptions using a try-catch block or declare them using the throws keyword in the method signature.

Unchecked Exceptions

Unchecked exceptions are the exceptions that are not checked at compile-time. They are subclasses of RuntimeException. Examples of unchecked exceptions include NullPointerException, ArrayIndexOutOfBoundsException, and ArithmeticException. It is not mandatory to handle unchecked exceptions explicitly, although it’s good practice to do so.

Checked Exception vs Unchecked Exception

Checked exceptions are those that are checked by the compiler for smooth program execution. Examples include HallTicketMissingException, PenNotWorkingException, and FileNotFoundException. If there is a chance of raising a checked exception in our program, we must handle it either by using try-catch blocks or by declaring it with the throws keyword; otherwise, we will get a compile-time error.

Unchecked exceptions, on the other hand, are not checked by the compiler for whether the programmer handles them or not. Examples include ArithmeticException and BomBlastException.

Note: Regardless of whether an exception is checked or unchecked, every exception occurs at runtime only; there is no chance of an exception occurring at compile time.

Note: RuntimeException and its child classes, as well as Error and its child classes, are unchecked. All other exceptions are checked.

Fully Checked vs Partially Checked

A checked exception is fully checked if all its child classes are also checked, e.g., IOException and InterruptedException. A checked exception is partially checked if only some of its child classes are unchecked, such as Exception and Throwable.

Exception Behavior Description:

• IOException: Checked (fully)
• RuntimeException: Unchecked
• InterruptedException: Checked (fully)
• Error: Unchecked
• Throwable: Checked (partially)
• ArithmeticException: Unchecked
• NullPointerException: Unchecked
• Exception: Checked (partially)
• FileNotFoundException: Checked (fully)

Customized Exception Handling by Using Try-Catch

It is highly recommended to handle exceptions. The code that may raise an exception is called risky code, and we have to define that code inside the try block. The corresponding handling code should be defined inside the catch block.

try {
    // Risky code
} catch(Exception e) {
    // Handling code
}

Without Try-Catch

class Test {
    public static void main(String[] args) {
        System.out.println("stmt 1");
        System.out.println(10/0);
        System.out.println("stmt 3");
    }
}

Output:

stmt 1
RE: ArithmeticException: / by zero

Abnormal Termination

With Try-Catch

class Test {
    public static void main(String[] args) {
        System.out.println("stmt 1");
        try {   
            System.out.println(10/0);
        } catch(ArithmeticException e) {
            System.out.println(10/2);
        }
        System.out.println("stmt 3");
    }
}

Output:

Stmt 1
5
Stmt 3

Normal Termination

In the first example without try-catch, the program encounters an ArithmeticException due to division by zero, leading to abnormal termination. In the second example with try-catch, the exception is caught, and the program continues executing the remaining statements, resulting in normal termination.

Control Flow in Try-Catch

try {
    stmt1;
    stmt2;
    stmt3;
} catch(Exception e) {
    stmt4;
}
stmt5;

Case 1: If there is no exception, then output will be (1, 2, 3, 5, Normal Termination).

Case 2: If an exception is raised at statement 2 and the corresponding catch block is matched, then the output will be (1, 4, 5, Normal Termination).

Case 3: If an exception is raised at statement 2 and the corresponding catch block is not matched, then the output will be (1, Abnormal Termination).

Case 4: If an exception is raised at statement 4 or statement 5, then it is always an abnormal termination.

Note:

1. Within the try block, if an exception is raised anywhere, then the rest of the try block won’t be executed, even if we handle that exception. Therefore, within a try block, we should only place risky code, and the length of the try block should be as short as possible.
2. In addition to the try block, there may be a chance of an exception occurring inside catch and finally blocks. If any statement outside the try block raises an exception, then it always results in an abnormal termination.

Methods to Print Exception Information

The Throwable class defines the following methods to print exception information:

printStackTrace(): This method prints the exception’s name, description, and stack trace, showing the sequence of method calls that led to the exception.

Printable Format:

NameOfException: Description
Stack Trace

toString(): Returns a string representation of the exception, including its name and description.

Name of Exception: Description

getMessage(): Returns the description of the exception.

Description

Example Program:

class Test {
    public static void main(String[] args) {
        try {
            System.out.println(10/0);
        } catch(ArithmeticException e) {
            e.printStackTrace(); // java.lang.ArithmeticException: / by zero at Test.main(Test.java:4)
            System.out.println(e); // java.lang.ArithmeticException: / by zero
            System.out.println(e.toString()); // java.lang.ArithmeticException: / by zero
            System.out.println(e.getMessage()); // / by zero
        }
    }
}

Note: Internally, the default exception handler will use printStackTrace() to print stack trace information to the console.

try with multiple catch blocks

The way of handling an exception varies from exception to exception; hence, for every exception type, it is highly recommended to use a separate catch block. Using try with multiple catch blocks is always possible and recommended.

Worst Programming Practice:

try {
    // Risky code
} catch(Exception e) {
    // For all exceptions, use this single catch block
}

Best Programming Practice:

try {
    // Risky Code
} catch(ArithmeticException e) {
    // Perform alternative arithmetic operation
} catch(SqlException e) {
    // Use MySQL DB instead of Oracle DB
} catch(FileNotFoundException e) {
    // Use a local file instead of a remote file
} catch(Exception e) {
    // Default exception handling
}

In the best programming practice approach, each specific exception type is caught and handled appropriately, providing a more tailored and robust error-handling mechanism.

Important Loopholes

Some important loopholes in exception handling:

1. Order of catch blocks matters

If a try with multiple catch blocks is present, then the order of catch blocks is very important. We have to take the child exceptions first and then the parent exceptions; otherwise, we will get a compile-time error saying “Exception XXX has already been caught”.

try {
    // Risky code
} catch (Exception e) {
    // Parent exception catch block
} catch (ArithmeticException e) {
    // Child exception catch block
}

// CE: Exception java.lang.ArithmeticException has already been caught

The correct code order should be:

try {
    // Risky code
} catch (ArithmeticException e) {
    // Child exception catch block
} catch (Exception e) {
    // Parent exception catch block
}

2. Cannot declare duplicate catch blocks

We cannot declare two catch blocks for the same exception; otherwise, we will get a compile-time error.

try {
    // Risky code
} catch (ArithmeticException e) {
    // Catch block for ArithmeticException
} catch (ArithmeticException e) {
    // Another catch block for ArithmeticException (Duplicate)
}

// CE: Exception java.lang.ArithmeticException has already been caught

The correct code should be:

try {
    // Risky code
} catch (ArithmeticException e) {
    // Catch block for ArithmeticException
} catch (Exception e) {
    // Catch block for other exceptions
}

These loopholes highlight the importance of careful handling and structuring of catch blocks to ensure effective exception management in Java programs.

Difference between final, finally, and finalize

final

• final is a modifier applicable for classes, methods, and variables.
• If a class is declared as final, then we can’t extend that class, meaning we can’t create a child class for that class. Inheritance is not possible for final classes.
• If a method is final, then we can’t override that method in the child class. If a variable is declared as final, then we can’t perform reassignment for that variable.

finally

• finally is a block always associated with try-catch to maintain clean-up code.
• The speciality of the finally block is that it will be executed always, irrespective of whether an exception is raised or not, and whether it is handled or not.
• It is responsible for performing clean-up activities related to the try block. Any resources opened as part of the try block will be closed inside the finally block.

try {
    // Risky code
} catch (Exception e) {
    // Handling code
} finally {
    // Clean-up code
}

finalize()

• finalize() is a method always invoked by the garbage collector just before destroying an object to perform clean-up activities.
• Once the finalize() method completes, immediately the garbage collector destroys that object.
• It is responsible for performing clean-up activities related to the object. Any resources associated with the object will be deallocated before destroying the object using the finalize() method.

Note:

The finally block is responsible for performing clean-up activities related to the try block. Any resources opened as part of the try block will be closed inside the finally block. It ensures that resources are released regardless of whether an exception occurs or not.

On the other hand, the finalize() method is responsible for performing clean-up activities related to the object. It is invoked by the garbage collector just before destroying an object. Any resources associated with the object will be deallocated before destroying the object using the finalize() method. This method is used to release resources held by the object and perform any necessary clean-up actions before the object is removed from memory.

In short, final is used to denote immutability or prevent extension/overriding, finally is used for try-catch cleanup, and finalize() is used for object-specific cleanup just before garbage collection. Each serves a distinct purpose in Java programming.

Various Possible Combinations of Try-Catch-Finally

Rules:

1. Order is Important: In try-catch-finally, the order is important, the order should be try, catch, and then finally.
2. Compulsory Usage: Whenever we write try, it’s compulsory to include either catch or finally; otherwise, we will get a compile-time error (try without catch or finally is invalid).
3. Compulsory Try Block for Catch: Whenever we write a catch block, a try block must be present; catch without try is invalid.
4. Compulsory Try Block for Finally: Whenever we write a finally block, a try block should be present; finally without try is invalid.
5. Nesting of Try-Catch-Finally: Inside try-catch-finally blocks, we can nest additional try-catch-finally blocks; nesting of try-catch-finally is allowed.
6. Curly Braces Requirement: Curly braces ({}) are mandatory for try-catch-finally blocks.

Examples:

Valid:

try {
  // code
} catch(X e) {
  // exception handling code
}

Valid:

try {
  // code
} catch(X e) {
  // exception handling code
} catch(Y e) {
  // exception handling code
}

Invalid:

try {
  // code
} catch(X e) {
  // exception handling code
} catch(X e) {
  // exception handling code
}

// CE: exception X has already been caught

Valid:

try {
  // code
} catch(X e) {
  // exception handling code
} finally {
  // cleanup code
}

Valid:

try {
  // code
} finally {
  // cleanup code
}

Valid:

try {
  // code
} catch(X e) {
  // exception handling code
} try {
  // code
} catch(Y e) {
  // exception handling code
}

Valid:

try {
  // code
} catch(X e) {
  // exception handling code
} try {
  // code
} finally {
  // cleanup code
}

Invalid:

try {
  // code
}
// CE: try without catch (or) finally

Invalid:

catch(X e) {
  // exception handling code
}
// CE: catch without try

Invalid:

finally {
  // cleanup code
}
// CE: finally without try

Invalid:

try {
  // code
} finally {
  // cleanup code
} catch(X e) {
  // exception handling code
}
// CE: catch without try 

Invalid:

try {
  // code
} System.out.println("Hello");
catch(X e) {
  // exception handling code
}
// CE1: try without catch or finally 
// CE2: catch without try

Invalid:

try {
  // code
} catch(X e) {
  // exception handling code
} System.out.println("Hello");
catch(Y e) {
  // exception handling code
}
// CE: catch without try

Invalid:

try {
  // code
} catch(X e) {
  // exception handling code
} System.out.println("Hello");
finally {
  // cleanup code
}
// CE: finally without try

Valid:

try {
  try {
    // code
  } catch(X e) {
    // exception handling code
  }
} catch(X e) {
}

Invalid:

try {
  try {
   // code
  }
} catch(X e) {
  // exception handling code
}
// CE: try without catch or finally 

Valid:

try {
  try {
    // code
  } finally {
    // cleanup code
  }
} catch(X e) {
  // exception handling code
}

Valid:

try {
  // code
} catch(X e) {
  try {
  } finally {
  }
}

Invalid:

try {
  // code
} catch(X e) {
 finally {
 }
}
// CE: finally without try

Valid:

try {
  // code
} catch(X e) {
  // exception handling code
} finally {
  try {
  } catch(X e) {
  }
}

Invalid:

try {
  // code
} catch(X e) {
  // exception handling code
} finally {
  finally {
  }
}
// CE: finally without try

Invalid:

try {
  // code
} catch(X e) {
  // exception handling code
} finally {
}
finally {
}
// CE: finally without try

Invalid:

try
 System.out.println("try");
catch(X e)
 System.out.println("catch");
finally
{
}
// CE: finally without try | Syntax error, insert "}" to complete Block

Invalid:

try{
  // code
}
catch(X e)
System.out.println("catch");
finally{
  // cleanup code
}
// CE: finally without try | Syntax error, insert "{" to complete Block

Invalid:

try {
  // code
} catch(X e) {
} finally
System.out.println("finally");

// CE: finally without try | Syntax error on token "System", invalid Expression

Valid:

try {
    try {
        // code
    } catch(Exception e) {
        // inner catch block
    } finally {
        // inner finally block
    }
} catch(Exception e) {
    // outer catch block
} finally {
    // outer finally block
}

These examples demonstrate the various valid and invalid combinations of try-catch-finally blocks according to the specified rules.

Throw (throw keyword)

The throw keyword is used to manually create and throw an exception object. Sometimes, we need to generate exception objects explicitly and hand them over to the JVM

throw new ArithmeticException("/ by zero");

Here, we are creating an ArithmeticException object explicitly and throwing it using the throw keyword.

The primary purpose of the throw keyword is to hand over our created exception object to the JVM manually.

The result of the following two programs is exactly the same:

Without throw keyword:

class Test {
    public static void main(String[] args) {
        System.out.println(10/0);
    }
}

Output:

Exception in thread "main" java.lang.ArithmeticException: / by zero
    at Test.main(Test.java:3)

In this case, the main method is responsible for causing the ArithmeticException and implicitly hands over the exception object to the JVM.

With throw keyword:

class Test {
    public static void main(String[] args) {
        throw new ArithmeticException("/ by zero");
    }
}

Output:

Exception in thread "main" java.lang.ArithmeticException: / by zero
    at Test.main(Test.java:3)

In this case, the programmer is explicitly creating an AE (ArithmeticException) object and throwing it using the throw keyword. This means the programmer is manually handing over the exception object to the JVM.

Note: The best use of the throw keyword is for user-defined or customized exceptions.

class Test {
    static AE e = new AE();
    public static void main(String[] args) {
        throw e;
    }
}


//Output - Runtime Error: AE

In this case, the throw keyword is used to throw a reference to an exception object e (AE object)

class Test {
    static AE e;
    public static void main(String[] args) {
        throw e;
    }
}


//Output - Runtime Error: NullPointerException

Here, e is a static member variable of type AE, but it is not initialized explicitly. Therefore, it defaults to null. When attempting to throw e, a NullPointerException occurs.

So, the throw keyword is used to explicitly throw exceptions, which can be either built-in or user-defined. However, it’s crucial to ensure that the exception object being thrown is properly initialized to avoid runtime errors like NullPointerException.

Unreachable Statement after throw:

After a throw statement, any code that follows it becomes unreachable because the exception is immediately thrown, and the program flow doesn’t continue beyond that point.

class Test {
    public static void main(String[] args) {
        System.out.println(10/0);
        System.out.println("Hello");
    }
}


//Runtime Error: AE: / by zero

Exception in thread "main" java.lang.ArithmeticException: / by zero
    at Test.main(Test.java:3)

Unreachable Statement Error:

If there are statements after a throw statement, they are considered unreachable, and the compiler raises a compile-time error indicating “unreachable statement”.

class Test {
    public static void main(String[] args) {
        throw new AE("/ by zero");
        System.out.println("Hello");
    }
}


//Compile Error: unreachable statement

Usage of throw with Non-Throwable Types:

The throw keyword is only applicable for throwable types (subclasses of Throwable). If we attempt to use it with non-throwable types, it results in a compile-time error due to incompatible types.

class Test {
    public static void main(String[] args) {
        throw new Test();
    }
}


//Compile Error: incompatible types, found: Test, required: java.lang.Throwable

Compilation Error: incompatible types
    found:    Test
    required: java.lang.Throwable

Inheriting from RuntimeException:

If a class extends RuntimeException, it becomes a throwable type, and instances of this class can be thrown using the throw keyword.

class Test extends RuntimeException {
    public static void main(String[] args) {
        throw new Test();
    }
}


// runtime exception

Exception in thread "main" Test
    at Test.main(Test.java:3)

In this example, Test is a subclass of RuntimeException, so it can be thrown without any compilation errors. When executed, it results in a runtime exception.

Throws (throws keyword)

In Java, if there is a possibility of a checked exception being thrown within a method, the method must either handle the exception using a try-catch block or declare that it throws the exception using the throws keyword in its method signature.

import java.io.*;

class Test {
    public static void main(String[] args) {
        PrintWriter pw = new PrintWriter("abc.txt");
        pw.println("Hello");
    }
}


//Compilation Error: unreported exception java.io.FileNotFoundException; must be caught or declared to be thrown

Here, the PrintWriter constructor throws a checked exception FileNotFoundException, which is not handled. Hence, a compilation error occurs.

To handle this error, you can either use a try-catch block to handle the exception:

import java.io.*;

class Test {
    public static void main(String[] args) {
        try {
            PrintWriter pw = new PrintWriter("abc.txt");
            pw.println("Hello");
        } catch (FileNotFoundException e) {
            // Handle the exception
            e.printStackTrace();
        }
    }
}

Or we can declare that the method throws the exception using the throws keyword:

import java.io.*;

class Test {
    public static void main(String[] args) throws FileNotFoundException {
        PrintWriter pw = new PrintWriter("abc.txt");
        pw.println("Hello");
    }
}

Using the throws keyword delegates the responsibility of handling the exception to the caller of the method.

Note: It’s recommended to handle exceptions using try-catch blocks where possible, as using throws may propagate exceptions up the call stack without handling them properly.

Let’s take one more example,

class Test {
    public static void main(String[] args) {
        Thread.sleep(10000);
    }
}

//CE: unreported exception java.lang.InterruptedException must be caught or declared to be thrown

The Thread.sleep() method may throw an InterruptedException, which is a checked exception. Since this exception is not handled within the main method, nor is it declared using the throws keyword in the method signature, the compiler raises a compilation error:

Here, we can declare that the method throws the exception using the throws keyword:

class Test {
    public static void main(String[] args) throws InterruptedException {
        Thread.sleep(10000);
    }
}

Using the throws keyword delegates the responsibility of handling the exception to the caller of the method. However, it’s important to handle exceptions properly to prevent unexpected behavior in the program.

By Using throws Keyword

The throws keyword in Java is used in method declarations to indicate that a method might throw certain exceptions during its execution. This alerts the caller of the method that they need to handle or propagate these exceptions.

class Test {
    public static void main(String[] args) throws InterruptedException {
        Thread.sleep(10000);
    }
}

In this example, the main method uses the throws keyword to declare that it might throw an InterruptedException during its execution. This means that if the sleep() method within main throws an InterruptedException, the caller of main (in this case, the JVM) must handle it.

Similarly, if a method calls another method that declares a checked exception using throws, the calling method must either handle that exception or re-throw it using throws.

class Test {
    public static void main(String[] args) throws IE {
        doStuff();
    }

    public static void doStuff() throws IE {
        doMoreStuff();
    }

    public static void doMoreStuff() throws IE {
        Thread.sleep(10000);
    }
}

In this example, the doStuff method declares that it might throw an IE (hypothetical checked exception). Consequently, since main calls doStuff, it must either handle IE or declare that it throws it, as it propagates up the call stack from doMoreStuff().

However, it’s important to note that using throws doesn’t prevent abnormal termination of the program; it’s merely a way to indicate potential exceptions that might be thrown. Additionally, throws is only required for checked exceptions; there’s no impact or requirement for unchecked exceptions.

throws clause

1. The throws clause can be used to delegate the responsibility of exception handling to the caller, whether it is a method or the JVM.
2. It is required only for checked exceptions; the usage of the throws keyword for unchecked exceptions has no impact.
3. It is required only to convince the compiler; the usage of throws does not prevent the abnormal termination of the program.

Note: It is recommended to use try-catch blocks over the throws keyword.

Case 1: We can use the throws keyword for methods and constructors, but not for classes.

class Test throws Exception   //invalid 
{
    Test() throws Exception   // valid 
    {
    }
    public void m1() throws Exception  //valid  
    {
    }
}

Case 2: We can use the throws keyword only for throwable types. If we try to use it for normal Java classes, we will get a compile-time error saying ‘incompatible types.

class Test
{
    public void m1() throws Test
    {
    }
}

// Compile Error: Incompatible types
// Found: Test
// Required: java.lang.Throwable

Case 3:

class Test
{
    public static void main(String[] args)
    {
        throw new Exception(); // Exception is checked
    }
}

//Compile Error: Unreported exception java.lang.Exception; must be caught or declared to be thrown

class Test
{
    public static void main(String[] args)
    {
        throw new Error(); // Error is unchecked
    }
}

//Runtime Error: 
Exception in thread "main" java.lang.Error
at Test.main(Test.java:lineNumber)

Case 4: Within a try block, if there is no chance of raising an exception, then we can’t write a catch block for that exception; otherwise, we will get a compilation error: ‘Exception XXX is never thrown in the body of the corresponding try statement.’ However, this rule is applicable only for fully checked exceptions.

class Test
{
    public static void main(String[] args)
    {
        try 
        {
            System.out.println("Hello");
        }
        catch(AE e)   // AE is unchecked exception 
        {
        }
    }
}

Examples and Outputs

class Test
{
    public static void main(String[] args)
    {
        try 
        {
            System.out.println("Hello");
        }
        catch(AE e)   // AE is unchecked exception 
        {
        }
    }
}

/////////////////////////////////////////////////

class Test 
{
    public static void main(String[] args)
    {
        try
        {
            System.out.println("hello");
        }
        catch(Exception e)   // partially checked 
        {
        }
    }
}

//////////////////////////////////////////////////////////////////

class Test
{
    public static void m(String[] args)
    {
        try
        {
            System.out.println("Hello");
        }
        catch(Error e)  // unchecked
        {
        }
    }
}

// Output - hello (in all three cases)

import java.io.*;
class Test
{
    public static void main(String[] args)
    {
        try
        {
            System.out.println("Hello");
        }
        catch(IOException e)   // Fully checked
        {
        }
    }
}

// Compile Error: Exception java.io.IOException is never thrown in the body of the corresponding try statement


////////////////////////////////////////////////////////////////////////////////////////

class Test
{
    public static void main(String[] args)
    {
        try
        {
            System.out.println("Hello");
        }
        catch(InterruptedException e)  // fully checked
        {
        }
    }
}

// Compile Error: Exception java.lang.InterruptedException is never thrown in the body of the corresponding try statement

Customized or user-defined exception

Sometimes, to meet programming requirements, we can define our own exceptions. Such types of exceptions are called customized or user-defined exceptions, e.g., TooYoungException, TooOldException, InsufficientFundsException, etc.

class TooYoungException extends RuntimeException {
    TooYoungException(String s) {
        super(s);
    }
}

class TooOldException extends RuntimeException {
    TooOldException(String s) {
        super(s);
    }
}

class CustomizedExceptionDemo {
    public static void main(String[] args) {
        int age = Integer.parseInt(args[0]);
        if (age > 60) {
            throw new TooYoungException("Please wait some more time; definitely, you will get the best match.");
        } else if (age < 18) {
            throw new TooOldException("Your age already crossed the marriage age, and there is no chance of getting married.");
        } else {
            System.out.println("You will get match details soon by email!");
        }
    }
}

Note:

1. The throw keyword is best suitable for user-defined or customized exceptions but not for predefined exceptions.
2. It is highly recommended to define customized exceptions as unchecked, i.e., we have to extend RuntimeException but not Exception.

In the example, why is super(s) required?

• super(s) is required to pass the description message to the superclass constructor, making it available to the default exception handler.

Exception Handling CheatSheet

Exception handling keyword summary

1. try –> Used to encapsulate risky code.
2. catch –> Used to handle exceptions.
3. finally –> Used to execute cleanup code.
4. throw –> Used to manually pass our created exception object to the JVM.
5. throws –> Used to delegate the responsibility of exception handling to the caller.

Various possible compiler errors in exception handling

1. “Unreported exception XXX; must be caught or declared to be thrown.”
2. “Exception XXX has already been caught.”
3. “Exception XXX is never thrown in the body of the corresponding try statement.”
4. “Unreachable statement.”
5. “Incompatible types: found: Test, required: java.lang.Throwable.”
6. “Try without catch or finally.”
7. “Catch without try.”
8. “Finally without try.”

Top 10 Exceptions in Java

Exceptions in Java are divided into two categories based on the entity raising them:

1. JVM Exception: These exceptions are raised automatically by the JVM whenever particular events occur. Examples include ArithmeticException and NullPointerException.
2. Programmatic Exception: These exceptions are raised explicitly, either by the programmer or by API developers, to indicate that something has gone wrong. Examples include TooOldException and IllegalArgumentException.

Top Ten Exceptions

1. ArrayIndexOutOfBoundsException: This exception is a subclass of RuntimeException and hence is unchecked. It is automatically raised by the JVM when attempting to access an array element with an index that is out of the array’s range. For example:

int[] x = new int[4]; // Indices 0 to 3
System.out.println(x[0]); // 0
System.out.println(x[10]); // Throws ArrayIndexOutOfBoundsException
System.out.println(x[-10]); // Throws ArrayIndexOutOfBoundsException

2. NullPointerException: This exception is a subclass of RuntimeException and hence is unchecked. It is automatically raised by the JVM when attempting to perform any operation on a null object. For example:

String s = null;
System.out.println(s.length()); // Throws NullPointerException

3. ClassCastException: This exception is a subclass of RuntimeException and hence is unchecked. It is automatically raised by the JVM when attempting to type cast a parent object to a child type.

Valid example:

String s = new String("durga");
Object o = (Object)s;

Invalid example:

Object o = new Object();
String s = (String)o;
// Throws ClassCastException

4. StackOverflowError: This error is a subclass of Error and hence is unchecked. It is automatically raised by the JVM when attempting to perform a recursive method call.

class Test {
    public void m1() {
        m2();
    } 

    public void m2() {
        m1();
    }

    public static void main(String[] args) {
        Test t = new Test();
        t.m1();
    }
}

The recursive method calls in this code snippet would lead to a StackOverflowError:

       .
       .
       .
       .
------------------
      m2()
------------------
      m1()
------------------
      m2()
------------------
      m1()
------------------
     main()
------------------



// RE : StackOverFlowError

5. NoClassDefFoundError: This error is a subclass of Error and hence is unchecked. It is automatically raised by the JVM when it is unable to find the required .class file. For example, if the Test.class file is not available, then attempting to run java Test will result in a runtime exception with the message: “NoClassDefFoundError: Test”.

6. ExceptionInInitializerError: This error is a subclass of Error and hence is unchecked. It is automatically raised by the JVM if any exception occurs while executing static variable assignments or static blocks.

class Test {
    static int x = 10/0;
}

// ExceptionInInitializerError 
         caused by java.lang.ArithmeticException: / by zero

Another example:

class Test {
    static {
        String s = null;
        System.out.println(s.length());
    }
}


// ExceptionInInitializerError caused by: java.lang.NullPointerException

7. IllegalArgumentException: This exception is a subclass of RuntimeException and hence is unchecked. It is raised explicitly either by the programmer or by API developers to indicate that a method has been invoked with an illegal argument. For example, suppose the valid range of thread priority is 1 to 10. If we attempt to set the priority with any other value, then we will get a RuntimeException with the message “IllegalArgumentException”

Thread t = new Thread();
t.setPriority(7); // Valid
t.setPriority(15); // Throws IllegalArgumentException

8. NumberFormatException: This exception is a direct subclass of IllegalArgumentException and indirectly a subclass of RuntimeException, making it unchecked. It is raised explicitly either by the programmer or API developers to indicate that a conversion from a string to a number has been attempted, but the string is not properly formatted.

int i = Integer.parseInt("10"); // Valid
int i = Integer.parseInt("ten"); // Throws NumberFormatException

9. IllegalStateException: This exception is a subclass of RuntimeException and hence is unchecked. It is raised explicitly either by the programmer or API developers to indicate that a method has been invoked at the wrong time. For example, after starting a thread, we are not allowed to restart the same thread once again; otherwise, we will get a RuntimeException with the message “IllegalThreadStateException”.

// Example of IllegalThreadStateException
Thread t = new Thread();
t.start();
t.start(); // Throws IllegalStateException

10. AssertionError: This exception is a subclass of Error and hence is unchecked. It is raised explicitly by the programmer or by API developers to indicate that an assert statement fails. For example, if the condition x > 10 is not met, then we will get a RuntimeException with the message “AssertionError”.

// Example of AssertionError
int x = 5;
assert(x > 10); // Throws AssertionError

Raised by:

Raised automatically by the JVM and hence these are JVM exceptions:

• ArrayIndexOutOfBoundsException
• NullPointerException
• ClassCastException
• StackOverflowError
• NoClassDefFoundError
• ExceptionInInitializerError

Raised explicitly either by the programmer or by API developer and hence these are programmatic exceptions:

• IllegalArgumentException
• NumberFormatException
• IllegalStateException
• AssertionError

Java 1.7v Enhancements in Exception Handling

As part of version 1.7, two concepts were introduced for exception handling:

1. Try-with-Resources
2. Multi-catch block

Until version 1.6, it was highly recommended to write a finally block to close resources that were opened as part of a try block:

try {
    br = new BufferedReader(new FileReader("input.txt"));
    // Use br based on our requirement
} catch (IOException e) {
    // Handling code
} finally {
    if (br != null) {
        br.close();
    }
}

The problems with the above approach are:

• The programmer is required to close resources inside the finally block, increasing the complexity of programming.
• The finally block is mandatory, which increases the length of the code and reduces readability.

To overcome these problems, the developers introduced try-with-resources in version 1.7.

The main advantage of try-with-resources is that whatever resources we open as part of the try block will be closed automatically once control reaches the end of the try block, either normally or abnormally. Therefore, explicit closure is not required, reducing the complexity of programming. Additionally, there’s no need to write a finally block, which reduces the length of the code and improves readability.

1.7v Try with Resources

In version 1.7, the try-with-resources statement was introduced:

try (BR br = new BR(new FR("input.txt"))) {
    // Use br based on our requirement 
    // br will be closed automatically once control reaches the end of the try block, either normally 
    // or abnormally, and we are not responsible for closing it explicitly
} catch (IOException e) {
    // Handling code
}

In this syntax, resources declared within the parentheses after the try keyword are automatically closed when the try block exits, whether normally or due to an exception. This feature simplifies resource management and improves code readability.

Try with Multiple Resources (1.7v)

In version 1.7, it became possible to declare and manage multiple resources in a single try-with-resources statement. These resources should be separated with semicolons:

try (R1; R2; R3) {
    // Code block
}

For example:

try (FileWriter fw = new FileWriter("Output.txt"); FileReader fr = new FileReader("input.txt")) {
    // Code block
}

All resources specified within the try-with-resources statement must implement the AutoCloseable interface. A resource is considered AutoCloseable if the corresponding class implements the java.lang.AutoCloseable interface.

It’s worth noting that many I/O-related, database-related, and network-related resources already implement the AutoCloseable interface. As programmers, we are not required to do anything specific other than being aware of this feature.

AutoCloseable Interface in Java 1.7v

The AutoCloseable interface was introduced in version 1.7 and contains only one method: close().

All resource variables declared within a try-with-resources statement are implicitly final. Therefore, within a try block, we cannot perform reassignment to these variables; otherwise, we will encounter a compilation error. For example:

import java.io.*;

class TryWithResources {
    public static void main(String[] args) throws Exception {
        try (BufferedReader br = new BufferedReader(new FileReader("input.txt"))) {
            br = new BufferedReader(new FileReader("output.txt")); // Compilation Error
        }
    }
}

Compilation Error:

AutoCloseable resource 'br' may not be assigned.
BufferedReader br = new BufferedReader(new FileReader("Output.txt"));

Until version 1.6, the try block should be associated with either catch or finally. However, from version 1.7 onward, we can use try-with-resources without explicitly specifying catch or finally blocks:

try (R) {
    // Code block
}

The main advantage of try-with-resources is that we are not required to write a finally block explicitly because we do not need to close resources explicitly. Therefore, until version 1.6, the finally block was considered essential, but from version 1.7 onward, it becomes unnecessary.

Multi-Catch Block

Until version 1.6, even if multiple different exceptions required the same handling code, separate catch blocks had to be written for each exception type. This approach increased the length of the code and reduced readability:

try {
    // Code block
} catch (AE e) {
    e.printStackTrace();
} catch (IOException e) {
    e.printStackTrace();
} catch (NPE e) {
    System.out.println(e.getMessage());
} catch (InterruptedException e) {
    System.out.println(e.getMessage());
}

To overcome this problem, the developers introduced the multi-catch block in version 1.7. With multi-catch blocks, a single catch block can handle multiple different types of exceptions:

try {
    // Code block
} catch (AE | IOException e) {
    e.printStackTrace();
} catch (NPE | InterruptedException e) {
    System.out.println(e.getMessage());
}

The main advantage of this approach is that the length of the code is reduced, and readability is improved.

class MultiCatchBlock {
    public static void main(String[] args) {
        try {
            System.out.println(10/0);
            String s = null;
            System.out.println(s.length());
        } catch (AE | NullPointerException e) {
            System.out.println(e);
        }
    }
}

In the above example, whether the raised exception is AE or NPE, the same catch block can handle it.

In a multi-catch block, there should not be any relation between exception types, such as child-to-parent, parent-to-child, or same type; otherwise, a compilation error will occur.

try {
    // Code block
} catch (AE | Exception e) { 
    e.printStackTrace();
}

//Compilation Error: Alternatives in a multi-catch statement cannot be related by subclassing.

Exception Propagation: Inside a method, if an exception is raised and not handled, the handling will be propagated to the caller. Then, the caller method is responsible for handling the exception. This process is called exception propagation.

Re-throwing Exception: This approach is used to convert one exception to another exception.

try {
    System.out.println(1 / 0);
} catch (AE e) {
    throw new NullPointerException();
}

Conclusion

Exception handling is an essential aspect of Java programming that enables developers to write robust and reliable code. By understanding the different types of exceptions, using try-catch blocks effectively, and following best practices for exception handling, you can create Java applications that gracefully handle errors and unexpected situations. Remember to handle exceptions appropriately, provide informative error messages, and clean up resources properly to ensure the reliability and maintainability of your code.

Multithreading is a programming concept that enables simultaneous execution of multiple threads within a process, allowing for better resource utilization and improved performance. In recent years, advancements in hardware and software technologies have led to significant enhancements in multithreading techniques. In this blog, we’ll delve into the latest multithreading enhancements and their implications for software development.

Thread Group: First Multithreading Enhancements

Based on functionality, we can group a thread into a single unit, which is nothing but a thread group. That is, a thread group contains a group of threads. In addition to threads, a thread group also contains sub-thread groups.

The main advantage of maintaining threads in the form of thread groups is that we can perform common operations easily.

Every thread in Java belongs to some group. The main thread belongs to the main group. Every thread group in Java is a child group of the system group, either directly or indirectly. Hence, the system group acts as the root for all thread groups in Java. The system group contains several system-level threads like finalizer, reference handler, signal dispatcher, and attach listener.

class Test {
  public static void main(String[] args) {
    System.out.println(Thread.currentThread().getThreadGroup().getName());  // Output: main 
    System.out.println(Thread.currentThread().getThreadGroup().getParent().getName());  // System
                         // main thread      main ThreadGroup  System TG System
  }
}

Here, “main thread” belongs to “main ThreadGroup,” and “System ThreadGroup” belongs to “System.”

Thread Group Constructors

ThreadGroup is a Java class present in the java.lang package and is a direct child class of Object.

Constructors:

ThreadGroup g = new ThreadGroup(String gName);

// Example usage:
ThreadGroup g = new ThreadGroup("First Group");

This constructor creates a new thread group with the specified name. The parent of this new group is the thread group of the currently executing thread.

ThreadGroup g = new ThreadGroup(ThreadGroup tg, String groupName);


// Example usage:
ThreadGroup g1 = new ThreadGroup("First Group")
System.out.println(g1.getParent().getName());  // main
ThreadGroup g2 = new ThreadGroup(g1, "Second Group");
System.out.println(g2.getParent().getName());  // First Group

This constructor creates a new thread group with the specified group name. The parent of this new thread group is the specified parent group.

In the above example, the parent group for “Second Group” is explicitly set to “First Group,” demonstrating the flexibility of this constructor.

Thread Group Methods

Various methods present in ThreadGroup:

1. String getName(): Returns the name of the ThreadGroup.
2. int getMaxPriority(): Retrieves the maximum priority of the thread group.
3. void setMaxPriority(int priority): Sets the maximum priority of the thread group. The default maximum priority is 10. Threads in the thread group that already have a higher priority won’t be affected, but for newly added threads, this maximum priority is applicable.

// Example usage:
ThreadGroup g1 = new ThreadGroup("tg");
Thread t1 = new Thread(g1, "Thread1");
Thread t2 = new Thread(g1, "Thread2");
g1.setMaxPriority(3);
Thread t3 = new Thread(g1, "Thread3");
System.out.println(t1.getPriority()); // 5
System.out.println(t2.getPriority()); // 5
System.out.println(t3.getPriority()); // 3

4. ThreadGroup getParent(): Returns the parent group of the current thread group.
5. void list(): Prints information about the thread group to the console.
6. int activeCount(): Returns the number of active threads present in the thread group.
7. int activeGroupCount(): Returns the number of active thread groups present within the current thread group.
8. int enumerate(Thread[] t): Copies all active threads of this thread group into the provided Thread[] array. This includes threads from sub-thread groups.
9. int enumerate(ThreadGroup[] g): Copies all active sub-thread groups into a ThreadGroup[] array.
10. boolean isDaemon(): Checks whether the thread group is a Daemon or not.
11. void setDaemon(boolean daemon): Sets the Daemon nature of the current thread group.
12. void interrupt(): Interrupts all waiting or sleeping threads present in the thread group.
13. void destroy(): Destroys the thread group and its sub-thread groups.

java.util.concurrent package

Problems with traditional synchronized keyword

Let’s first see the problems with the traditional synchronized keyword, then we will look at enhancements

The problems with the traditional synchronized keyword are:

1. Lack of Flexibility: There is no flexibility to attempt for locks without waiting.
2. Absence of Time Constraints: There is no way to specify the maximum waiting time for a thread to acquire a lock. Threads may wait indefinitely for a lock, potentially leading to performance problems or deadlock situations.
3. Lack of Control Over Lock Acquisition: When a thread releases a lock, there is no control over which waiting thread will acquire that lock next.
4. No API for Listing Waiting Threads: There is no API available to list out all waiting threads for a lock.
5. Limitation in Usage Scope: The synchronized keyword must be used either at the method level or within a method, and it’s not possible to use it across multiple methods.

To address these issues, the creators introduced java.util.concurrent.locks in version 1.5. This package provides several enhancements to programmers, offering more control over concurrency.

The Lock interface

Lock object is similar to the implicit lock acquired by a thread to execute a synchronized method or synchronized block. Lock implementations provide more extensive operations than traditional implicit locks.

Important methods of the Lock interface:

void lock()

We can use this method to acquire a lock. If the lock is already available, then the current thread will immediately get that lock. If the lock is not available, then it will wait until obtaining the lock. It exhibits the same behavior as the traditional synchronized keyword.

boolean tryLock()

Attempts to acquire the lock without waiting. If the lock is available, the thread acquires the lock and returns true. If the lock is not available, the method returns false, and the thread can continue its execution without waiting. In this case, the thread never enters a waiting state.

if (lock.tryLock()) {
    // Perform safe operations
} else {
    // Perform alternative operations
}

boolean tryLock(long time, TimeUnit unit)

boolean tryLock(long time, TimeUnit unit)

If the lock is available, the thread will get the lock and continue its execution. If the lock is not available, then the thread will wait until the specified amount of time. If the lock is still not available after the specified time, the thread can continue its execution. TimeUnit: An enum present in the java.util.concurrent package.

if (lock.tryLock(1000, TimeUnit.MILLISECONDS)) {
    // Perform safe operations
}

void lockInterruptibly(): Acquires the lock if it is available and returns immediately. If the lock is not available, it will wait. While waiting, if the thread is interrupted, it won’t get the lock.

void unlock(): To call this method, the current thread should be the owner of the lock; otherwise, a runtime exception IllegalMonitorStateException will be thrown.

ReentrantLock

It is an implementation class of the Lock interface and is a direct child class of Object.

Reentrant means a thread can acquire the same lock multiple times without any issue. Internally, ReentrantLock increments the thread’s personal count whenever we call lock methods and decrements the count value whenever the thread calls the unlock method. The lock will be released whenever the count reaches zero.

Constructors:

ReentrantLock l = new ReentrantLock();  

Creates an instance of ReentrantLock.

ReentrantLock l = new ReentrantLock(boolean fairness);

• Creates a ReentrantLock with the given fairness policy. If fairness is set to true, then the longest waiting thread will get the lock if it is available, following a first-come-first-serve policy. If fairness is set to false, the selection of the waiting thread is not guaranteed.

Which of the following declarations are equal?

• ReentrantLock l = new ReentrantLock();
• ReentrantLock l = new ReentrantLock(true);
• ReentrantLock l = new ReentrantLock(false);

The first and third declarations are equal.

Important methods of ReentrantLock:

(Comes from the Lock interface)

• void lock()
• boolean tryLock()
• boolean tryLock(long l, TimeUnit t)
• void lockInterruptibly()
• void unlock()

Extra methods:

• int getHoldCount(): Returns the number of holds on this lock by the current thread.
• boolean isHeldByCurrentThread(): Returns true if the lock is held by the current thread.
• int getQueueLength(): Returns the number of threads waiting for the lock.
• Collection getQueuedThreads(): Returns a collection of threads that are waiting to acquire the lock.
• boolean hasQueuedThreads(): Returns true if any thread is ready to acquire the lock.
• boolean isLocked(): Returns true if the lock is acquired by the same thread.
• boolean isFair(): Returns true if the fairness policy is set to true.
• Thread getOwner(): Returns the thread that acquired the lock.

Thread Pools (Executor Frameworks)

Creating a new thread for every job may lead to performance and memory problems. To overcome this, we should use a thread pool. A thread pool is a pool of already created threads ready to execute our jobs. Java 1.5 introduced the Executor Framework to implement thread pools.

We can create a thread pool as follows:

ExecutorService service = Executors.newFixedThreadPool(3);

We can submit a Runnable job using the submit method, e.g., service.submit(job);.

service.submit(job);.

We can shutdown the ExecutorService by using shutdown(), e.g., service.shutdown();.

service.shutdown();.

Callable and Future

In the case of a Runnable job, the thread won’t return anything after completing its job. If a thread is required to return some result after execution, then we should use Callable. The Callable interface contains only one method, call(). If we submit a Callable object to the executor, then after completing the job, the thread returns an object of type Future. The Future object can be used to retrieve the result from the Callable job.

Runnable vs Callable

Runnable:

1. If a thread is not required to return anything after completing a job, then we should use Runnable.
2. The Runnable interface contains only one method, run().
3. A Runnable job does not return anything; hence, the return type of run() is void.
4. Within the run method, if there is any chance of a raised checked exception, we must handle it using try-catch because we can’t use the throws keyword with the run method.
5. The Runnable interface is present in the java.lang package.
6. Introduced in version 1.0.

Callable:

1. If a thread is required to return something after completing a job, then we should use Callable.
2. The Callable interface contains only one method, call().
3. A Callable job is required to return something, and hence the return type of the call method is object.
4. Inside the call method, if there is any chance of raising a checked exception, we are not required to handle it using try-catch because the call method already throws exceptions.
5. The Callable interface is present in the java.util.concurrent package.
6. Introduced in version 1.5.

ThreadLocal

The ThreadLocal class provides thread-local variables. The ThreadLocal class maintains values on a per-thread basis. Each ThreadLocal object maintains a separate value for each thread that accesses that object. Threads can access their local value, manipulate its value, and even remove its value. In every part of the code executed by a thread, we can access its variable.

For example, consider a servlet that invokes some business methods. We have a requirement to generate a unique transaction ID for every request, and we have to pass this transaction ID to the business methods. For this requirement, we can use ThreadLocal to maintain a separate transaction ID for every request, i.e., for every thread.

Once a thread enters into a dead state, all its local variables are by default eligible for garbage collection.

This allows for safe, efficient handling of thread-specific data without worrying about synchronization issues or interference from other threads. It ensures that each thread operates with its own set of data, isolated from other threads.

Conclusion

Multithreading enhancements are ongoing, driven by the need for faster, more responsive, and scalable software. These advancements improve concurrency, performance, debugging, and security, making multithreading a powerful and versatile tool for modern software development. As hardware and software continue to evolve, we can expect even more innovative and efficient multithreading techniques to emerge in the future.

In multi-threaded programming, communication between threads is essential for coordinating their activities and sharing data. Inter-thread communication in Java refers to the mechanisms through which threads communicate with each other to synchronize their actions or exchange data. This communication enables threads to work cooperatively towards achieving a common goal. In this blog, we will explore the concepts of inter-thread communication in Java, including synchronization, shared memory, and the wait-notify mechanism.

Why Inter-Thread Communication?

Consider a scenario where multiple threads are executing concurrently and need to coordinate their tasks or exchange information. For instance, one thread may produce data, while another consumes it. In such cases, inter-thread communication becomes necessary to ensure the correct execution and synchronization of threads.

Java provides several mechanisms for inter-thread communication, including synchronized blocks, wait-notify, and locks. These mechanisms allow threads to coordinate their activities effectively and avoid issues such as race conditions and deadlock.

Inter-thread communication

Two threads can communicate with each other by using wait(), notify(), and notifyAll(). The thread that is expecting an update is responsible for calling wait(), after which the thread enters a waiting state. The thread responsible for performing the update should call notify() after completing the update, allowing the waiting thread to receive the notification and continue its execution with the updated items.

Why are wait(), notify(), and notifyAll() present in the Object class but not in the Thread class? wait(), notify(), and notifyAll() are present in the Object class rather than the Thread class because a thread can call these methods on any Java object.

To call wait(), notify(), and notifyAll() methods on any object, the thread must be the owner of that object, meaning it must hold the lock of that object. Therefore, these methods can only be called from within a synchronized area; otherwise, a IllegalMonitorStateException will be thrown.

If a thread calls wait() on any object, it immediately releases the lock of that particular object and enters a waiting state.

If a thread calls notify() on any object, it releases the lock of that object, but it may not happen immediately. Unlike wait(), notify(), and notifyAll(), there are no other methods where a thread releases a lock.

Hence, in the cases of yield(), join(), and sleep(), the thread does not release the lock, but it does release the lock in wait(), notify(), and notifyAll().

Prototypes of methods:

public final void wait() throws InterruptedException
public final native void wait(long ms) throws InterruptedException 
public final void wait(long ms, int ns) throws InterruptedException 

public final native void notify()
public final native void notifyAll()

Note: Every wait() method throws InterruptedException, which is a checked exception. Therefore, whenever we use the wait() method, we must handle this InterruptedException, either with a try-catch block or by using the throws keyword; otherwise, a compile-time error will occur.

What is impact of these methods on thread lifecycle?

The wait(), notify(), and notifyAll() methods in Java have a significant impact on the lifecycle of threads. These methods are primarily used for inter-thread communication and synchronization. Let’s explore their impact on the lifecycle of threads:

wait()

• Impact on Thread Lifecycle: When a thread calls the wait() method, it voluntarily gives up its hold on the object’s monitor (lock) and enters into the “waiting” state. This means that the thread is temporarily suspended and does not consume CPU resources until one of the following conditions occurs:
  • Another thread calls notify() or notifyAll() on the same object.
  • The specified timeout period elapses (if wait(long timeout) is used).
• Transition in Thread Lifecycle: From the “waiting” state, a thread can transition back to the “runnable” state (ready to run) once it is notified or the timeout expires.
• Example Use Case: Typically used to wait for a specific condition to be met or for another thread to complete its task before proceeding.

notify()

• Impact on Thread Lifecycle: The notify() method is used to wake up a single thread that is waiting on the object’s monitor. If multiple threads are waiting, the choice of which thread to wake up is arbitrary and depends on the JVM’s implementation.
• Transition in Thread Lifecycle: When notify() is called, the awakened thread transitions from the “waiting” state to the “runnable” state. However, it does not immediately acquire the object’s monitor. It competes with other threads to obtain the lock once it becomes available.
• Example Use Case: Often used to signal that a condition has changed and other threads waiting on that condition can proceed.

notifyAll()

• Impact on Thread Lifecycle: Similar to notify(), but notifyAll() wakes up all threads that are waiting on the object’s monitor. All awakened threads transition to the “runnable” state and compete for the object’s monitor.
• Transition in Thread Lifecycle: Threads waiting on the object’s monitor are awakened and transitioned to the “runnable” state. They compete for the lock once it becomes available.
• Example Use Case: Useful when multiple threads are waiting for a shared resource to become available or when a significant change occurs that affects multiple threads.

Example(Wait,Notify,NotifyAll)

class ThreadA {
    public static void main(String[] args) throws Exception {
        ThreadB b = new ThreadB();
        b.start();
        synchronized (b) {
            System.out.println("Main thread calling wait method"); // -----------------------------> 1
            b.wait();
            System.out.println("Main thread got notification"); //-----------------------------> 4
            System.out.println(b.total); // -----------------------------> 5
        }
    }
}

class ThreadB extends Thread {
    int total = 0;

    public void run() {
        System.out.println("Child thread starts calculation"); // ----------------------------->2
        for (int i = 1; i <= 100; i++) {
            total = total + i;
        }
        System.out.println("Child thread giving notification"); // ----------------------------->3
        this.notify();
    }
}

Main thread calling wait method
Child thread starts calculation 
Child thread giving notification 
Main thread got notification 
5050

Here,

• The main thread starts and creates an instance of ThreadB and starts it.
• Main thread enters a synchronized block with object b.
• The main thread calls wait() on b, releasing the lock and going into a waiting state.
• Meanwhile, ThreadB starts execution and calculates the sum.
• After calculation, ThreadB calls notify(), waking up the waiting main thread.
• The main thread resumes execution, prints “Main thread got notification”, and then prints the total sum calculated by ThreadB, which is 5050.

Producer-Consumer Problem

In the Producer-Consumer problem, the Producer thread is responsible for producing items to the queue, while the Consumer thread is responsible for consuming items from the queue. If the queue is empty, the Consumer thread calls the wait() method and enters a waiting state. After the Producer thread produces an item and adds it to the queue, it is responsible for calling notify(). This notification allows the waiting Consumer thread to resume execution and continue processing the updated items.

// Producer thread is responsible for producing items to the queue
class ProducerThread {
    void produce() {
        synchronized(q) {
            // Produce items to the queue
            q.notify();
        }
    }
}

// Consumer thread is responsible for consuming items from the queue
class ConsumerThread {
    void consume() {
        synchronized(q) {
            if (q.isEmpty())
                q.wait(); // If the queue is empty, consumer thread enters waiting state
            else
                consumeItems(); // Consume items from the queue
        }
    }
}

• In the Producer-Consumer Problem, there are two threads: ProducerThread and ConsumerThread.
• ProducerThread is responsible for producing items and ConsumerThread is responsible for consuming items.
• When ProducerThread produces an item, it notifies any waiting ConsumerThread by calling notify() after synchronizing on the queue object.
• ConsumerThread, after synchronizing on the queue object, checks if the queue is empty.
• If the queue is empty, ConsumerThread calls wait(), entering a waiting state until notified by the ProducerThread.
• Once ProducerThread produces an item and notifies, the waiting ConsumerThread gets the notification and continues its execution, consuming the items from the queue.

This process ensures that the ProducerThread and ConsumerThread synchronize their actions properly to avoid issues such as producing when the queue is full or consuming when the queue is empty.

Difference between notify() and notifyAll()

The notify() method is used to provide a notification to only one waiting thread. If multiple threads are waiting, only one thread will be notified, and the remaining threads have to wait for further notifications. Which thread will be notified cannot be predicted, as it depends on the JVM.

On the other hand, the notifyAll() method is used to provide notification to all waiting threads of a particular object. Even if multiple threads are notified, execution will be performed one by one because threads require a lock, and only one lock is available.

Using notify() and notifyAll() allows for controlling the synchronization and communication between threads effectively, depending on the specific requirements of the application.

Understanding Lock Acquisition in Synchronized Blocks with wait()

To unserstand this concept better, let’s first see blow eamples and then we will discuss it further.

Stack s1 = new Stack();
Stack s2 = new Stack();

synchronized(s1) {
    // ...
    s2.wait(); // This will result in an IllegalMonitorStateException
    // ...
}

We will encounter an IllegalMonitorStateException in the above case. This is because the wait() method is being called on object s2, but the synchronization block is held on object s1. Therefore, the thread does not have the lock for s2, leading to the illegal state exception.

However, in the second example:

synchronized(s1) {
    // ...
    s1.wait(); // This is a valid usage
    // ...
}

The above example is perfectly valid. Here, the wait() method is called on the same object s1 on which the synchronization block is held. Hence, the thread has the lock for s1, ensuring that the call to wait() is valid.

Note: When calling the wait() method on an object, the thread requires the lock of that particular object. For instance, if wait() is called on s1, the thread acquires the lock of s1 but not s2.

Deadlocks

Deadlocks occur primarily due to the use of the synchronized keyword, hence special care must be taken when using it. There are no resolution techniques for deadlocks, but several prevention techniques are available.

class A {
    public synchronized void d1(B b) {
        System.out.println("Thread 1 starts execution of d1() method");
        try {
            Thread.sleep(6000);
        } catch(InterruptedException e) {}
        System.out.println("Thread 1 trying to call B's last()");
        b.last();
    }

    public synchronized void last() {
        System.out.println("Inside A, this is last() method");
    } 
}

class B {
    public synchronized void d2(A a) {
        System.out.println("Thread 2 starts execution of d2() method");
        try {
            Thread.sleep(6000);
        } catch(InterruptedException e) {}
        System.out.println("Thread 2 trying to call A's last()");
        a.last();
    }

    public synchronized void last() {
        System.out.println("Inside B, this is last() method");
    }
}

class DeadLock1 extends Thread {
    A a = new A();
    B b = new B();

    public void m1() {
        this.start();
        a.d1(b);  // This line executed by main thread
    }

    public void run() {
        b.d2(a); // this line executed by child thread 
    }

    public static void main(String[] args) {
        DeadLock1 d = new DeadLock1();
        d.m1();
    }
}

Output-

Thread 1 starts execution of d1() method
Thread 2 starts execution of d2() method
Thread 2 trying to call A's last()
Thread 1 trying to call B's last()

In the above program, if we remove any single synchronized keyword, then the program won’t enter into a deadlock. Therefore, the synchronized keyword is the only reason for the deadlock situation. Due to this, special care must be taken when using synchronized keywords.

Deadlock Versus Starvation

Deadlock occurs when threads are blocked forever because they are each waiting for a resource that the other thread holds. It results in a situation where no progress can be made.

On the other hand, starvation refers to a situation where a thread is unable to gain regular access to shared resources and is unable to make progress. However, the waiting of the thread in starvation eventually ends at certain points.

For example, if a low priority thread has to wait until completing all high priority threads, it will experience long waiting but will eventually get a chance to execute, which is a form of starvation.

Daemon Threads

Daemon threads are those executing in the background without interfering with the termination of the main application. Examples of daemon threads include the Garbage Collector, Signal Dispatcher, and Attach Listener.

The main objective of daemon threads is to provide support for non-daemon threads (such as the main thread). For instance, if the main thread is running with low memory, the JVM may run the garbage collector to reclaim memory from unused objects. This action improves the amount of free memory, allowing the main thread to continue its execution smoothly.

Usually, daemon threads have low priority, but depending on our requirements, they can run with high priority as well.

We can check if a thread is a daemon thread by using the isDaemon() method of the Thread class:

public boolean isDaemon()

Similarly, we can change the daemon nature of a thread using the setDaemon() method of the Thread class, but this change is only possible before starting the thread. If we attempt to change the daemon nature after starting the thread, we will encounter an IllegalThreadStateException.

Default Nature of Thread

The default nature of thread is such that the main thread is always non-daemon, while for all other threads, the daemon nature is inherited from their parent thread. This means that if the parent thread is a daemon, then the child thread will also be a daemon, and if the parent thread is non-daemon, then the child thread will also be non-daemon.

It is impossible to change the daemon nature of the main thread because it is already started by the JVM at the beginning.

For example:

class MyThread extends Thread {
}

class Test {
    public static void main(String[] args) {
        System.out.println(Thread.currentThread().isDaemon()); // false
        // Thread.currentThread().setDaemon(true);  // This will result in IllegalThreadStateException
        MyThread t = new MyThread();
        System.out.println(t.isDaemon()); // false
        t.setDaemon(true);
        System.out.println(t.isDaemon()); // true
    }
}

When the last non-daemon thread terminates, all daemon threads are automatically terminated regardless of their position.

For example:

class MyThread extends Thread {
    public void run() {
        for(int i = 0; i < 10; i++) {
            System.out.println("Child thread");
            try {
                Thread.sleep(2000);
            } catch(InterruptedException e) {}
        }
    }
}

class DaemonThreadDemo {
    public static void main(String[] args) {
        MyThread t = new MyThread();
        t.setDaemon(true); // This makes the child thread a daemon
        t.start();
        System.out.println("End of main thread");
    }
}

If we comment out line 1 (t.setDaemon(true);), then both the main and child threads are non-daemon, and both threads will execute until their completion. However, if line 1 is not commented, the main thread is non-daemon, and the child thread is daemon. In this case, when the main thread terminates, the child thread will also be terminated. The possible outputs in this case are:

//output 1

End of main thread
Child Thread


//output 2

End of main thread


//output 3

Child Thread
End of main thread
```"

Multithreading Models

Java multithreading concepts are implemented using the following two models:

1. Green Thread Model: Threads managed entirely by the JVM without relying on underlying OS support are called green threads. Very few operating systems, such as SUN Solaris, provide support for the green thread model. However, the green thread model is deprecated and not recommended for use.
2. Native OS Model: Threads managed by the JVM with the assistance of the underlying operating system are referred to as the native OS model. All Windows-based operating systems provide support for the native OS model.

How to stop a thread?

If the stop() method is called, the thread immediately enters the dead state. However, the stop() method is deprecated and not recommended for use.

How to suspend and resume a thread?

The suspend() and resume() methods are used to suspend and resume threads, respectively. However, these methods are deprecated and not recommended for use.

When the suspend() method is called, the thread immediately enters the suspended state. A suspended thread can be resumed using the resume() method of the Thread class, allowing the suspended thread to continue its execution.

Part 5:

Conclusion

Inter-thread communication is essential in Java multi-threaded programming for coordinating the activities of concurrent threads. By using synchronization and mechanisms like the wait-notify protocol, threads can communicate effectively and synchronize their actions to avoid issues such as race conditions and deadlock. Understanding these concepts is crucial for writing thread-safe and efficient concurrent programs in Java.

In the realm of concurrent programming, synchronization plays a crucial role in ensuring thread safety and preventing race conditions. In Java, where multithreading is a fundamental feature, understanding synchronization mechanisms is essential for writing robust and efficient concurrent applications. In this comprehensive guide, we will delve into the intricacies of synchronization in Java threads, exploring its concepts, techniques, and best practices.

Synchronization in Java

Synchronization in Java is a critical concept for managing concurrent access to shared resources, preventing data inconsistency issues that can arise when multiple threads operate on the same data simultaneously.

“Synchronized”

The ‘synchronized’ keyword is the modifier applicable only to methods and blocks, but not to classes and variables. If multiple threads are trying to operate simultaneously, there may be a chance of a data inconsistency problem. To overcome this problem, we should use the “synchronized” keyword. If a method or block is declared as synchronized, then at any given time, only one thread is allowed to execute that method or block on the given object, resolving the data inconsistency problem.

The main advantage of the “synchronized” keyword is that we can resolve data inconsistency problems, but the main disadvantage is that it increases the waiting time of threads and creates performance problems. Hence, if there is no specific requirement, it is not recommended to use the “synchronized” keyword.

If a thread wants to execute a synchronized method on the given object, it first has to obtain the lock of that object. Once the thread has obtained the lock, it is allowed to execute any synchronized method on that object. Once the method execution is complete, the thread automatically releases the lock. Acquiring and releasing the lock are internally taken care of by the JVM, and the programmer is not responsible for this activity.

While a thread is executing a synchronized method on a given object, the remaining threads are not allowed to execute any synchronized methods simultaneously on the same object, but they are allowed to execute non-synchronized methods simultaneously.

class X {
    synchronized m1() {
    }
    
    synchronized m2() {
    }
    
    m3() {
    }
}

If thread t1 comes to execute m1() on object x, then t1 only acquires the lock of object x and starts executing m1(). Now, if t2 comes to execute m1() or t3 comes to execute m2(), then in both situations, a waiting state will occur. However, if t4 comes to execute m3(), it will get a chance immediately.

The lock concept is implemented based on the object, not on the method. So, every Java object has two areas:

1. Non-synchronized area: This area can be accessed by any number of threads simultaneously, for example, wherever the object’s state won’t be changed, like a read() operation.
2. Synchronized area: This area can be accessed by only one thread at a time, for example, wherever we are performing update operations (Add/Remove/Delete/Replace), i.e., where the state of the object is changing.

Real-time Example:

class ReservationSystem {
    CheckAvailability() {           // Non-synchronized 
        // Just read operation
    }
    
    synchronized bookTicket() {       //Synchronized 
        // Update
    }
}

Synchronized Demo

class Display {
  public synchronized void wish(String name) { 
    for(int i=0; i<10; i++) {
      System.out.print("Good Morning:");
      try {
         Thread.sleep(2000);
      } catch(InterruptedException e) {
      }
      System.out.println(name);
    }
  }
}

class MyThread extends Thread {
 Display d;
 String name;
 MyThread(Display d, String name) {
   this.d = d;
   this.name =  name;
 }
 public void run() {
   d.wish(name);
 }
}

class SynchronizedDemo {
 public static void main(String[] args) {
   Display d = new Display();
   MyThread t1 = new MyThread(d, "Krushna");
   MyThread t2 = new MyThread(d, "Arjuna");
   t1.start();
   t2.start();
 }
}

Here, (d object).wish(“Krushna”) by t1 | .wish(“Arjuna”) by t2

In the SynchronizedDemo class, two threads t1 and t2 are created, both sharing the same Display object d. The wish() method of the Display class is synchronized, ensuring that only one thread can execute it at a time. This prevents data inconsistency issues.

Suppose,

If we do not declare the wish() method as synchronized, then both threads will be executed simultaneously, resulting in irregular output like below:

Good Morning:Good Morning:Arjuna
Good Morning:Krushna
Good Morning:Arjuna
Good Morning:Krushna
Good Morning:Good Morning:Arjuna
Good Morning:Krushna
Good Morning:Arjuna
Good Morning:Krushna
Good Morning:Good Morning:Arjuna
Good Morning:Krushna
Good Morning:Arjuna
Good Morning:Krushna

But, if we declare wish() as synchronized, then at a time only one thread is allowed to execute wish() on the given Display object, ensuring regular output.

Good Morning:Krushna
Good Morning:Krushna
Good Morning:Krushna
Good Morning:Krushna
Good Morning:Krushna
Good Morning:Krushna
Good Morning:Krushna
Good Morning:Krushna
Good Morning:Krushna
Good Morning:Krushna
Good Morning:Arjuna
Good Morning:Arjuna
Good Morning:Arjuna
Good Morning:Arjuna
Good Morning:Arjuna
Good Morning:Arjuna
Good Morning:Arjuna
Good Morning:Arjuna
Good Morning:Arjuna
Good Morning:Arjuna

As expected, each thread prints its name (“Krushna” for t1 and “Arjuna” for t2) ten times alternately, resulting in regular output due to the synchronization of the wish() method.

Case Study

Display d1 = new Display();
Display d2 = new Display();

MyThread t1 = new MyThread(d1, "Krushna");
MyThread t2 = new MyThread(d2, "Arjuna");

t1.start();
t2.start();

In this case study, eventhough the wish() method is synchronized, we will get irregular output because threads are operating on different Java objects.

Conclusion: If multiple threads are operating on the same Java object, then synchronization is required. If multiple threads are operating on multiple Java objects, then synchronization is not required.

Every class in Java has a unique lock, which is known as the class-level lock. If a thread wants to execute a static synchronized method, it requires the class-level lock. Once the thread acquires the class-level lock, it is allowed to execute any static synchronized method of that class. Once the method execution completes, the thread automatically releases the lock.

While a thread is executing a static synchronized method, the remaining threads are not allowed to execute any static synchronized method of that class simultaneously. However, the remaining threads are allowed to execute the following methods simultaneously:

• static m3() (normal static method)
• synchronized m4() (normal synchronized instance method)
• m5() (normal instance methods)