java 私有对象锁,对象锁定私有类成员 - 最佳实践？ （Java）

I asked a similar question the other day but wasn't satisfied with the response, mainly because the code I supplied had some issues that people focused on.

Basically, what is the best practice for locking private members in Java? Assuming each private field can only be manipulated in isolation and never together (like in my Test class example below), should you lock each private field directly (example 1), or should you use a general lock object per private field you wish to lock (example 2)?

Example 1: Lock private fields directly

class Test {

private final List xList = new ArrayList();

private final List yList = new ArrayList();

/* xList methods */

public void addToX(Object o) {

synchronized(xList) {

xList.add(o);

}

}

public void removeFromX(Object o) {

synchronized(xList) {

xList.remove(o);

}

}

/* yList methods */

public void addToY(Object o) {

synchronized(yList) {

yList.add(o);

}

}

public void removeFromY(Object o) {

synchronized(yList) {

yList.remove(o);

}

}

}

Example 2: Use lock objects per private field

class Test {

private final Object xLock = new Object();

private final Object yLock = new Object();

private List xList = new ArrayList();

private List yList = new ArrayList();

/* xList methods */

public void addToX(Object o) {

synchronized(xLock) {

xList.add(o);

}

}

public void removeFromX(Object o) {

synchronized(xLock) {

xList.remove(o);

}

}

/* yList methods */

public void addToY(Object o) {

synchronized(yLock) {

yList.add(o);

}

}

public void removeFromY(Object o) {

synchronized(yLock) {

yList.remove(o);

}

}

}

解决方案

Personally I prefer the second form. No other code at all can use that reference (barring reflection, debugging APIs etc). You don't need to worry about whether the internal details of the list tries to synchronize on it. (Any method you call on a list obviously has access to this, so could synchronize on it.) You're purely using it for locking - so you've also got separation of concerns between "I'm a lock" and "I'm a list".

I find that way it's easier to reason about the monitor, as you can easily see all the possible code that uses it.

You may wish to create a separate class purely for use as monitors, with an override for toString() which could help with diagnostics. It would also make the purpose of the variable clearer.

Admittedly this approach does take more memory, and usually you don't need to worry about code locking on this... but I personally feel that the benefit of separating the concerns and not having to worry about whether that code does lock on itself outweighs the efficiency cost. You can always choose to go for the first form if you find that the "wasted" objects are a performance bottleneck for some reason (and after you've analyzed the code in the class you're potentially going to synchronize on).

(Personally I wish that both Java and .NET hadn't gone down the "every object has an associated monitor" route, but that's a rant for a different day.)