CODEWITHSUNDEEP
javamultithreadingvector
St.Antario
St.Antario

Reputation: 27425

Understanding Vector synchrnoization policy

I'm reading B. Goetz Java Concurrency In Practice and now I'm at the section adding functionality to existing thread-safe classes. He stated:

The synchronization policy of Vector is fixed by its specification, so BetterVector would not suffer from this problem.

@ThreadSafe
public class BetterVector<E> exends Vector<E>{
    public synchronized boolean putIfAbsent(E x){
        boolean absent = !contains(x);
        if(absent)
            add(x);
        return absent;
    }
}

So, I tried to figure out myself about synchronization policy of Vector and could only find that

Unlike the new collection implementations, Vector is synchronized.

Does it mean that it synchronized by this object? Or it may mean synchronization by any (probably private) object. If so, BetterVector<E> is extremely fragile because it depends on the current implementation of the synchronization policy that is no even specified clearly.

Upvotes: 2

Views: 105

Answers (2)

Alex Suo
Alex Suo

Reputation: 3129

I don't quite understand your term "synchronization policy" here. The definition of synchronized keyword can be found in Java language spec at https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html.

A synchronized method (§8.4.3.6) automatically performs a lock action when it is invoked; its body is not executed until the lock action has successfully completed. If the method is an instance method, it locks the monitor associated with the instance for which it was invoked (that is, the object that will be known as this during execution of the body of the method). If the method is static, it locks the monitor associated with the Class object that represents the class in which the method is defined. If execution of the method's body is ever completed, either normally or abruptly, an unlock action is automatically performed on that same monitor.

How the locking is translated into OS level call is up to the JVM implementation. However, since the behavior of such keyword has to be defined as above in the Java Language Spec (otherwise this JVM isn't following Java standard), it's guaranteed that the Java programmer writing such statement would achieve the result he wants i.e. such method is thread safe upon using synchronized keyword.

Upvotes: 1

Thomas Stets
Thomas Stets

Reputation: 3045

That is a very good question. You are right that the way Vector is synchronized does not seem to be specified. (At least, I could find no specification).

However, the current implementation synchronizes on the object itself, and not on an internal object. While this implementation could change at any time, it is unlikely to happen. Too much code probably relies on the current implementation. A change might break all kind of things. I doubt that the code maintainers will take that risk.

My guess is, that code relying on the current implementation is theoretically extremely fragile, in practice there is little risk due to the rather conservative code maintenance and public oversight of the Java development process.

Upvotes: 1

Related Questions