Is RMI Thread Safe?

When the thread safety question extends to the remote calls, e.g. RMI, it becomes even more interesting.

According to the specification defined with Java 1.4.2, RMI section 3.2,

A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Since remote method invocation on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is thread-safe.

No matter how confusing this specification is, it at least tells us two things,

1. RMI does not take care of the thread safety, it leaves the thread safety as it is.
2. RMI does not give you one server thread for one client thread, actually, it guarantees nothing on the thread scheduling.

It sounds a little bit discouraging, but it is good enough already since it does not break the thread safety either.

As long as both the client objects and the server objects are thread-safe, the application is thread-safe.

Please! Don't Thread Safe Everything!

Thread safe is good, but please, don't do it everywhere. Do it only when instances will be used concurrently by multiple threads. We have three reasons to say that.

• Unnecessary synchronized method invocations (and synchronized blocks) can cause unnecessary blocking and unblocking of threads, which can hurt performance.

• Immutable objects tend to be instantiated more often, leading to greater numbers of often short-lived objects that can increase the work of the garbage collector.

• Synchronization gives rise to the possibility of deadlock, a severe performance problem in which your program appears to hang.

None of these performance setbacks are good excuses for neglecting to make classes that need to thread-safe so, but they do constitute good reasons not to make classes thread-safe unnecessarily.

Way to Thread Safety - Wrapper

Wrapper is to embed an object in a thread-safe wrapper object. In this approach you leave the original class (which isn't thread-safe) unchanged and create a separate class that is thread-safe. Instances of the new class serve as thread-safe "front ends" to instances of the original class.

This approach makes the most sense when you want to give clients a choice between a version of a class that is thread-safe and one that isn't. It also makes sense when you're a client of someone else's class that isn't thread-safe, but you need to use the class in a multithreaded environment. Once you define your own thread-safe wrapper for the class, you can safely use the class in a multithreaded environment by going through your wrapper.

A good example of this approach from the Java API comes from the 1.2 collections library. The 1.2 collections library defines a hierarchy that includes classes that represent many kinds of collections -- none of which are thread-safe. But class Collection includes several class methods that will enclose a regular collection object in a thread-safe wrapper, so you can safely use the object in a multithreaded context. This design gives users of the collections library a choice of using a collections object that is thread-safe and one that isn't.

Note that a common attribute of wrapper classes like those you would use to add thread safety to the enclosed object is that the wrapper accepts the same messages as the enclosed object. In other words, often a wrapper class will descend from a common superclass or superinterface with the enclosed class. (For those of you familiar with the Design Patterns book by Gamma, et. al., this is the "decorator" pattern.) This decorator design approach to wrappers, which is exhibited by the thread-safe wrappers of the 1.2 collections library, allows the thread safety to be dynamically added or removed from an object.

Way to Thread Safety - Immutable

An immutable object is one whose state can't be changed once the object is created. Immutable objects are, by their very nature, thread-safe simply because threads have to be able to write to an object's instance variables to experience a read/write or write/write conflict. Because no methods (only the constructor) of an immutable object actually write to the object's instance variables, the object is by definition thread-safe.

In this approach to making an object thread-safe, you don't mark critical sections as synchronized. Instead, you separate out the critical sections that read instance variables from those that write to instance variables. The critical sections that read are left as-is. The critical sections that write must be changed so that, instead of altering the current object's instance variables, they create a new object that embodies the new state and returns a reference to that object.

It works well when objects are small and represent values of a simple abstract data type. The Java API includes several examples of immutable objects, including String and the primitive type wrappers such as Integer, Long, Float, Boolean, Character, and so on.

It also lets you pass references to them to methods without worrying that the method will change the object's state. In addition, if the overhead of immutability (excessive creation of short-lived objects) may at times be too inefficient, you can also define a mutable companion class that can be used when the immutable version isn't appropriate. An example of this design approach in the Java API is the StringBuffer class, which serves as a mutable companion to the immutable String class. Note that the StringBuffer class is also thread-safe, but it uses the "normal" approach: its instance variables are private and its critical sections are synchronized.

Way to Thread Safety - Synchronization

The most straightforward way to correct the unruly behavior exhibited by non thread safe objects when placed in a multithreaded context is to synchronize the object's critical sections.

An object's critical sections are those methods or blocks of code within methods that must be executed by only one thread at a time. Put another way, a critical section is a method or block of code that must be executed atomically, as a single, indivisible operation. By using Java's synchronized keyword, you can guarantee that only one thread at a time will ever execute the object's critical sections.

This approach takes two steps, to make all relevant fields private, and to identify and synchronize all the critical sections.

Any field that you need to coordinate multithreaded access to must be private, otherwise it may be possible for other classes and objects to ignore your critical sections and access the fields directly. Not every field must be private - only those that will be involved in any temporarily invalid states created by the object's or class's critical sections. For example, constants (static final variables) can't be corrupted by multiple threads, so they needn't be private.

A critical section is a bit of code that must be executed atomically, that is, as a single, indivisible operation.

Note that reads and writes of primitive types and object references are atomic by definition, except for longs and doubles. This means that if you have an int, for example, that is independent of any other fields in an object, you needn't synchronize code that accesses that field. If two threads were to attempt to write two different values to the int concurrently, the resulting value would be one or the other. The int would never end up with a corrupted value made up of some bits written by one thread and other bits written by the other thread.

The same is not necessarily true, however, for longs and doubles. If two different threads were to attempt to write two different values to a long concurrently, you might just end up with a corrupted value consisting of some bits written by one thread and other bits written by the other thread. Multithreaded access to longs and doubles, therefore, should always be synchronized.

For example, a Price class has two instances variables, double priceValue and Date effectiveDate. And the class has a updatePrice method,

public void updatePrice(doubel priceValue, effectiveDate) {
this.priceValue = priceValue;
this.effectiveDate = effectiveDate;
}

The way to make Price thread safe is to make the priceValue and the effectiveDate private first,
then synchronize the updatePrice method.

public synchronized void updatePrice(double priceValue, effectiveDate) {
...
}

or

public void ... {
synchronized (this) {
this.priceValue = priceValue;
this.effectiveDate = effectiveDate;
}
}

Thread Safety - How to Tell

In a multithreaded environment, instances of non thread safe classes are susceptible to two kinds of misbehavior: write/write conflicts and read/write conflicts. From any of these two conflicts, you can tell that the class is not thread safe.

Write/write conflicts

Imagine two threads are trying to write to the same object's instance variables concurrently. If the thread scheduler interleaves these two threads in just the right way, the two threads will inadvertently interfere with each other, yielding a write/write conflict. In the process, the two threads will corrupt the object's state.

Read/write conflicts

This kind of conflict arises when an object's state is read and used while in a temporarily invalid state due to the unfinished work of another thread.

This is like the ACID characteristics of transactions. As long as it takes two or more steps to move an instance from one state to another state, the class is very unlikely thread safe.

Thread Safety - Where to Worry About

Given the architecture of the JVM, you need only be concerned with instance and class variables when you worry about thread safety. Because all threads share the same heap, and the heap is where all instance variables are stored, multiple threads can attempt to use the same object's instance variables concurrently. Likewise, because all threads share the same method area, and the method area is where all class variables are stored, multiple threads can attempt to use the same class variables concurrently. When you do choose to make a class thread-safe, your goal is to guarantee the integrity -- in a multithreaded environment -- of instance and class variables declared in that class.

You needn't worry about multithreaded access to local variables, method parameters, and return values, because these variables reside on the Java stack. In the JVM, each thread is awarded its own Java stack. No thread can see or use any local variables, return values, or parameters belonging to another thread.

Five Categories of Thread Safety

In his Effective Java, Joshua Bloch described five categories of thread safety: immutable, thread-safe, conditionally thread-safe, thread-compatible, and thread-hostile.

• Immutable objects are guaranteed to be thread-safe, and never require additional synchronization. Because an immutable object's externally visible state never changes, as long as it is constructed correctly, it can never be observed to be in an inconsistent state. Most of the basic value classes in the Java class libraries, such as Integer, String, and BigInteger, are immutable.
• Thread-safe classes are safe not only for single call, but also for multiple calls combined. They will need no additional synchronzation from their callers. This thread-safety guarantee is a strong one -- many classes, like Hashtable or Vector, will fail to meet this stringent definition.
• Conditionally thread-safe classes are those for which each individual operation may be thread-safe, but certain sequences of operations may require external synchronization. The most common example of conditional thread safety is traversing an iterator returned from Hashtable or Vector -- the fail-fast iterators returned by these classes assume that the underlying collection will not be mutated while the iterator traversal is in progress. To ensure that other threads will not mutate the collection during traversal, the iterating thread should be sure that it has exclusive access to the collection for the entirety of the traversal. Typically, exclusive access is ensured by synchronizing on a lock -- and the class's documentation should specify which lock that is (typically the object's intrinsic monitor).
• Thread-compatible classes are not thread-safe, but can be used safely in concurrent environments by using synchronization appropriately. This might mean surrounding every method call with a synchronized block or creating a wrapper object where every method is synchronized (like Collections.synchronizedList()). Or it might mean surrounding certain sequences of operations with a synchronized block. To maximize the usefulness of thread-compatible classes, they should not require that callers synchronize on a specific lock, just that the same lock is used in all invocations. Doing so will enable thread-compatible objects held as instance variables in other thread-safe objects to piggyback on the synchronization of the owning object. Many common classes are thread-compatible, such as the collection classes ArrayList and HashMap, java.text.SimpleDateFormat, or the JDBC classes Connection and ResultSet.
• Thread-hostile classes are those that cannot be rendered safe to use concurrently, regardless of what external synchronization is invoked. Thread hostility is rare, and typically arises when a class modifies static data that can affect the behavior of other classes that may execute in other threads. An example of a thread-hostile class would be one that calls System.setOut().

Generic Five Steps to Create JAX-RPC Web Service

The first stage is to write the interface to declare the remote methods to expose and to write the implementation class for those methods.

For the second stage, you typically run some kind of mapping tool to generate the WSDL description for the web service which maps the interface.

The third step is to run a mapping tool on the WSDL file to create the stub and tie classes which are required to allow remote client access.

The next step is to compile all the generated files and package them into an archive file, typically a WAR (Web Application Archive) file.

Finally, you deploy the web service onto a web server with a built-in SOAP engine.

Decompile .class in Eclipse

Don't you hate the "Source Not Found" while you are debugging in Eclipse?

OK yes, you can do this.

1. download JAD at http://www.kpdus.com/jad.html and then install it on your workstation.
2. download JAD Eclipse plugin at http://sourceforge.net/projects/jadclipse/ and then install it with your Eclipse.
3. restart your Eclipse and click Window->Preferences->Java->JadClipse and finish the configuration.

Congratulations! .class is no longer a black box.