Core java - Advance Topics
  • Welcome
  • Schedule
  • 1) Exception Handling
    • 1) Introduction to Exception Handling
    • 2) Categories of Exceptions
    • 3) Creating a method that throws an exception
    • 4) Creating Custom Exception Classes
    • 5)What happens when an exception is thrown?
      • 5.1) Creating try-catch-finally blocks
      • 5.2) Using a method that throws a checked exception
      • 5.3) Using a method that throws a runtime exception
      • 5.4) Using a method that throws an error
      • 5.5) Will a finally block execute even if the catch block defines a return statement?
      • 5.6) What happens if both a catch and a finally block define return statement?
      • 5.7) What happens if a finally block modifies the value returned from a catch block?
      • 5.8) Can a try block be followed only by a finally block?
      • 5.9) Does the order of the exceptions caught in the catch blocks matter?
      • 5.10) Can I rethrow an exception or the error I catch?
      • 5.11) Can I declare my methods to throw a checked exception instead of handling it?
      • 5.12) I can create nested loops, so can I create nested try-catch blocks too?
      • 5.13) Should I handle errors?
    • 6) Best Practices
    • 7) Cheat Sheet
    • 8) Problems
  • 2) Wrapper Classes and Enums
    • 2.1) Creating objects of the wrapper classes
    • Enums
  • 3) Inner Classes
    • 3.1) Static nested class (also called static inner class)
    • 3.2) Inner class (also called member class)
    • 3.3) Anonymous inner class
    • 3.4) Method local inner classes
    • CheatSheet
  • 4) Generics
    • Multiple Type parameters in Generic classes
    • Inheritance using Generics
    • Generic interfaces
    • Generic Methods
    • Bounded type parameters
    • Applications
  • 5) Equals and Hashcode
    • Problems
  • CompareTo method overview
  • Basic DS
    • 1) Simple Array List
    • 2) Simple HashMap
  • 5) Collections Framework - Part 1
    • Introducing the collections framework
    • Working with the Collection interface
      • The core Collection interface
      • Methods of the Collection interface
    • Creating and using List, Set, and Deque implementations
      • List interface and its implementations
      • Iterators
      • Sorting List using custom sorting technique
      • Comparable Interface
      • Custom Sorting using comparator
      • ArrayList - Examples and practice problems
    • Stack
    • Linked List
    • LinkedList Operations
  • 6) Collections Framework - Part 2
    • Sets
      • Set Types
      • Array to Set (vice versa)
    • Maps
    • TreeMap
    • Autoboxing And Unboxing
  • Collections Framework - Part 3
    • Basics : DS , Number System
    • Internal Working
      • HashMap
      • HashSet
  • 7) Reflection API
  • 8) Annotations
  • 9) Reading Input From Various Sources
    • File Handling
    • Reading From Xml
    • Reading From JSON
  • 10) Multi-threading (Concurrency)
    • Protect shared data
    • Thread-safe access to shared data
  • 11) Design Patterns
    • Singleton
    • DI
  • 12) Internal Working of JVM
  • 13) Garbage Collection
  • 14) More on Strings (Buffer and Builder)
  • 15) Cloning and Immutable Class
    • 16) Serialization And Deserialization
    • Untitled
  • JAVA 8
    • Interface Changes
    • Lambda
    • Method Ref
    • Optional
    • Streams
    • Predicates
  • Practice Tests
    • Test - Collections
    • OOPS
    • S-OOPS
Powered by GitBook
On this page
  • OBJECT LOCKS AND MONITORS:
  • SYNCHRONIZED STATEMENTS:

Was this helpful?

  1. 10) Multi-threading (Concurrency)

Thread-safe access to shared data

PreviousProtect shared dataNext11) Design Patterns

Last updated 6 years ago

Was this helpful?

Imagine if you could lock a shared object while it was being accessed by a thread; you’d be able to prevent other threads from modifying it. This is exactly what Java does to make its data thread safe. Making your applications thread safe means securing your shared data so that it stores correct data, even when it’s accessed by multiple threads. Thread safety isn’t about safe threads—it’s about safeguarding your shared data that might be accessible to multiple threads. A thread-safe class stores correct data without requiring calling classes to guard it.

You can lock objects by defining synchronized methods and synchronized statements. Java implements synchronization by using monitors.

OBJECT LOCKS AND MONITORS:

Every Java object is associated with a monitor, which can be locked or unlocked by a thread. At a time, only one thread can hold lock on a monitor and is referred to as the monitor owner. Owning the monitor is also referred to as acquiring the monitor. If another thread wants to acquire the monitor of that object, it must wait for it to be released.

When the keyword synchronized is added to a method, only one thread can execute it at a time. To execute a synchronized method, a thread must acquire the monitor of the object on which the method is called. When the monitor of an object is locked, no other thread can execute any synchronized method on that object. When acquired, a thread can release the lock on the monitor if

  • It has completed its execution.

  • It needs to wait for another operation to complete.

    For the first case, it releases the lock and exits. For the latter case, it enters a waiting set of threads that are waiting to acquire the monitor again. Threads enter the waiting set due to an execution of yield or wait. They can reacquire the monitor when notify- All() or notify() is called.

Figure below shows how a thread might have to wait to hold a lock on a monitor. Only one thread can own the monitor of an object, and a thread might release the monitor and enter a waiting state.

SYNCHRONIZED METHODS:

Synchronized methods are defined by prefixing the definition of a method with the key- word synchronized. You can define both instance and static methods as synchronized methods. The methods, which modify the state of instance or static variables, should be defined as synchronized methods. This prevents multiple threads from modifying the shared data in a manner that leads to incorrect values.

When a thread invokes a synchronized method, it automatically locks the monitor. If the method is an instance method, the thread locks the monitor associated with the instance on which it’s invoked (referred to as this within the method). For static methods, the thread locks the monitor associated with the Class object, thereby representing the class in which the method is defined. These locks are released once execution of the synchronized method completes, with or without an exception.

For nonstatic instance synchronized methods, a thread locks the monitor of the object on which the synchronized method is called. To execute static synchronized methods, a thread locks the monitor asso- ciated with the Class object of its class.

let’s modify the definition of class Book by defining its meth- ods newSale() and returnBook() as synchronized methods. The methods that belong to the data being protected are defined as synchronized.

Figure below shows how threads task2, task1, and task3 might acquire a lock on the monitor of object book defined in the main method of class ShoppingCart. As you see, a thread can’t execute synchronized methods newSale() and returnBook() on book without acquiring a lock on its monitor. So each thread has exclusive access to book to modify its state, resulting in a correct book state at the completion of main.

A thread releases the lock on an object monitor after it exits a synchronized method, whether due to successful completion or due to an exception.

Problem 1 :

As stated before, when a thread acquires a lock on the object monitor, no other thread can execute any other synchronized method on the object until the lock is released. This could become inefficient if your class defined synchronized methods that manipulate different sets of unrelated data. To do so, you might mark a block of statements with the keyword synchronized, as covered in the next section.

SYNCHRONIZED STATEMENTS:

To execute synchronized statements, a thread must acquire a lock on an object monitor. For an instance method, it might not acquire a lock on the instance itself. You can specify any object on which a thread must acquire the monitor lock before it can exe- cute the synchronized statements.

Multiple threads can concurrently execute methods with synchronized statements if they acquire locks on monitors of separate objects.

A thread releases the lock on the object monitor once it exits the synchronized state- ment block due to successful completion or an exception. If you’re trying to modify your shared data using synchronized statements, ensure that the data items are mutu- ally exclusive. As shown in the preceding example, the object references objSale and objPos refer to different objects.

A thread must own a monitor before it can execute synchronized code. Only the monitor owner can execute the synchronized code.
Threads acquire a lock on the monitor of object book before executing its synchronized methods newSale() and returnBook(). So threads task1, task2, and task3 don’t interleave.