How the Java virtual machine performs thread synchronization

Advertisement: Support JavaWorld, click here!

July 1997

HOME | FEATURED TUTORIALS | COLUMNS | NEWS & REVIEWS | FORUM | JW RESOURCES | ABOUT JW

ARCHIVE
TOPICAL INDEX

| Core Java
| Enterprise Java
| Micro Java
| Applied Java
| Java Community

JAVA Q&A INDEX
JAVA TIPS INDEX
JAVA BOOK INDEX
JavaWorld Services

| Newsletters
| Special Offers
| ProductFinder
| Education Resources
| White Paper Library

Under the Hood

# How the Java virtual machine performs thread synchronization

### The last in a series on Java bytecode, this article covers threads, shared data, locks, and more!

> Summary
> All Java programs are compiled into class files, which contain bytecodes, the machine language of the Java virtual machine. This article takes a look at how thread synchronization is handled by the Java virtual machine, including the relevant bytecodes. (1,750 words)

By Bill Venners

Printer-friendly version | Mail this to a friend

Page 1 of 2

Advertisement

his month's Under The Hood looks at thread synchronization in both the Java language and the Java virtual machine (JVM). This article is the last in the long series of bytecode articles I began last summer. It describes the only two opcodes directly related to thread synchronization, the opcodes used for entering and exiting monitors.

Threads and shared data
One of the strengths of the Java programming language is its support for multithreading at the language level. Much of this support centers on coordinating access to data shared among multiple threads.

The JVM organizes the data of a running Java application into several runtime data areas: one or more Java stacks, a heap, and a method area. For a backgrounder on these memory areas, see the first Under the Hood article: "The lean, mean virtual machine".

Inside the Java virtual machine, each thread is awarded a Java stack, which contains data no other thread can access, including the local variables, parameters, and return values of each method the thread has invoked. The data on the stack is limited to primitive types and object references. In the JVM, it is not possible to place the image of an actual object on the stack. All objects reside on the heap.

There is only one heap inside the JVM, and all threads share it. The heap contains nothing but objects. There is no way to place a solitary primitive type or object reference on the heap -- these things must be part of an object. Arrays reside on the heap, including arrays of primitive types, but in Java, arrays are objects too.

Besides the Java stack and the heap, the other place data may reside in the JVM is the method area, which contains all the class (or static) variables used by the program. The method area is similar to the stack in that it contains only primitive types and object references. Unlike the stack, however, the class variables in the method area are shared by all threads.

Object and class locks
As described above, two memory areas in the Java virtual machine contain data shared by all threads. These are:

- The heap, which contains all objects
- The method area, which contains all class variables

If multiple threads need to use the same objects or class variables concurrently, their access to the data must be properly managed. Otherwise, the program will have unpredictable behavior.

To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can "possess" at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the JVM for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread.

Class locks are actually implemented as object locks. When the JVM loads a class file, it creates an instance of class `java.lang.Class`. When you lock a class, you are actually locking that class's `Class` object.

Threads need not obtain a lock to access instance or class variables. If a thread does obtain a lock, however, no other thread can access the locked data until the thread that owns the lock releases it.

Monitors
The JVM uses locks in conjunction with monitors. A monitor is basically a guardian in that it watches over a sequence of code, making sure only one thread at a time executes the code.

Each monitor is associated with an object reference. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code.

When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.

Next page >
Page 1 How the Java virtual machine performs thread synchronization
Page 2 Multiple locks

Printer-friendly version | Mail this to a friend

Resources
- The book The Java virtual machine Specification (http://www.aw.com/cp/lindholm-yellin.html), by Tim Lindholm and Frank Yellin (ISBN 0-201-63452-X), part of The Java Series (http://www.aw.com/cp/javaseries.html), from Addison-Wesley, is the definitive Java virtual machine reference.

Previous "Under The Hood" articles:

- "The Lean, Mean Virtual Machine" Gives an introduction to the Java virtual machine.
- "The Java Class File Lifestyle" Gives an overview to the Java class file, the file format into which all Java programs are compiled.
- "Java's Garbage-Collected Heap" Gives an overview of garbage collection in general and the garbage-collected heap of the Java virtual machine in particular.
- "Bytecode Basics" Introduces the bytecodes of the Java virtual machine, and discusses primitive types, conversion operations, and stack operations in particular.
- "Floating Point Arithmetic" Describes the Java virtual machine's floating-point support and the bytecodes that perform floating point operations.
- "Logic and Arithmetic" Describes the Java virtual machine's support for logical and integer arithmetic, and the related bytecodes.
- "Objects and Arrays" Describes how the Java virtual machine deals with objects and arrays, and discusses the relevant bytecodes.
- "Exceptions" Describes how the Java virtual machine deals with exceptions, and discusses the relevant bytecodes.
- "Try-Finally" Describes how the Java virtual machine implements try-finally clauses, and discusses the relevant bytecodes.
- "Control Flow" Describes how the Java virtual machine implements control flow and discusses the relevant bytecodes.
- "The Architecture of Aglets" Describes the inner workings of Aglets, IBM's autonomous Java-based software agent technology.
- "The Point of Aglets" Analyzes the real-world utility of mobile agents such as Aglets, IBM's autonomous Java-based software agent technology.
- "Method Invocation and Return" Explains how the Java virtual machine invokes and returns from methods, including the relevant bytecodes.

Top Offers

T-Mobile Cell Phone Plans Motorola Free Cell Phones T-Mobile Cell Phone Plans Motorola Free Cell Phones

Personal Loans - Offers credit applications to a range of mortgage loans, auto loans, personal loans and credit cards.

Bad Credit Loans - Offers bad credit loan applications to a range of personal loans, mortgage loans, home equity, refinance and debt consolidation loans.

www.spammingbureau.com Spamming Bureau

Refinance Mortgage Mortgage refinancing, home loans and home equity loans

PriceSCAN Unbiased Price Comparisons, Vendor Ratings and User Reviews. Don't Buy It Before You PriceSCAN It!

Mortgage Leads Internet Mortgage Loan Leads Generation

California Home Loan California refinance mortgage lender and home equity loans.

Cheap Premium Tickets Your one stop shop for all sold out Sports, Concerts and Theatre events. Cheap Premium Tickets has seating for every venue across the country.

-->

Advertisement: Support JavaWorld, click here!

HOME | FEATURED TUTORIALS | COLUMNS | NEWS & REVIEWS | FORUM | JW RESOURCES | ABOUT JW | FEEDBACK Copyright © 2004 JavaWorld.com, an IDG company |