In concurrent code, what is the difference between, and the pros and cons of each:

  • Locking on data
  • Locking on functions

My understanding is that locking on data is better, and I think I'm doing it, but apparently I am not. Could anyone provide some clarification?


There's a subtle distinction between the two. Let's take a look the following sample code.

public class Foo {
    private static Object lockFunction = new Object();
    private static Bar myBar = new Bar();

    public void fooFunc(float someValue) {
        synchronized (lockFunction){                //locking against the function

    public void fooFunc2(float someValue1) {
        myBar.setValue(someValue2);             //Danger! unlocked access to myBar

    private void fooPrivates(float someValue){

public static class Bar {
    private static Object lockBarData = new Object();
    private float myValue;

    public float getValue() {
        synchronized (lockBarData) {            //technically not necessary since it's a read operation
            return myValue;

    public void setValue(value) {
        synchronized (lockBarData) {            //locking against the data
            myValue = value;

The danger with lockObject is that it is controlling access to calling the function fooPrivate. It exercises no control over other functions accessing the Bar object myBar. And if you happen to have static copies of myBar then you're going to have a single copy of myBar used by multiple copies of Foo.

lockBar on the other hand is controlling access to the private variable myValue within the Bar class.

In a trivial example like the one above, they'll both work because you can make sure that functions like FooFunc2 simply aren't allowed to work that way. But in a complex, multi-threaded application it gets easier for subtle situations to arise where myBar is manipulated without being controlled by a lock.

In my experience, locking against data is the better way to go.

When you lock against the function, you have to make sure that everything accessing that function operates the same way. It introduces greater governance concerns in order to make sure that non-conforming code doesn't sneak into the code base. Another concern with locking against the function is that you're generally holding the lock for a longer period of time than you would if you're locking against the data.

Locking against the data makes it easier to hide the implementation of the data object from users of the data. Even in the trivial example above, Foo doesn't necessarily know (or care!) that Bar needs to have a lock in place before anything can be done with myValue.

| improve this answer | |
  • I feel like the latter will have a lot more calls to lock. Aren't lock requests relatively expensive? – durron597 Dec 19 '14 at 16:51
  • Lock requests could be expensive, but I would worry about that cost until I was sure that my data access was correct and safe. From there, I'd profile the system to make sure it was operating within reasonable limits. And if there's a problem, I'll strip as much extra code out of the locked routine as possible. – user53019 Dec 19 '14 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.