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
            fooPrivates(someValue);
        }
    }

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

    private void fooPrivates(float someValue){
        myBar.setValue(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.