How many threads can simultaneously invoke an unsynchronized method of an object?

So let's say I have a class X with a method m. Method m is NOT synchronized and it doesn't need to be since it doesn't really change the state of the object x of type X.

In some threads I call the method like this: x.m(). All these threads use the same object x.

By how many threads can be this method (method m) called on object x simultaneously? Can be the fact that the method is called by, let's say, 100 threads a bottleneck for my applica开发者_如何学Gotion?

thanks.

---

Other's have answered your direct question.

I'd like to clear up something that is could be a misconception on your part ... and if it is, it is a dangerous one.

Method m is NOT synchronized and it doesn't need to be since it doesn't really change the state of the object x of type X.

That is not a sufficient condition. Methods that don't change state typically need to be synchronized too.

Suppose that you have a class Test with a simple getter and setter:

public class Test {
    private int foo;

    public int getFoo() {
        return foo;
    }

    public synchronized void setFoo(int foo) {
        this.foo = foo;
    }
}

Is the getter thread-safe?

• According to your rule, yes.
• In reality, no.

Why? Because unless the threads that call getFoo and setFoo synchronize properly, a call to getFoo() after a call to setFoo(...) may see a stale value for foo.

This is one of those nasty cases where you will get away with it nearly all of the time. But very occasionally, the timing of the two calls will be such that the bug bites you. This kind of bug is likely to slip through the cracks of your testing, and be very difficult to reproduce when it occurs in production.

---

The only case where it absolutely safe to access an object's state from multiple threads without synchronizing is when the state is declared as final, AND the constructor doesn't publish the object.

---

If you have more threads in the runnable state than you have physical cores, you'll end up wasting time by context switching... but that's about it. The fact that those threads are executing the same method is irrelevant if there's no coordination between them.

---

Remember the difference between threads and instances. One is executing the other is data. If the data is not under some locking mechanism, or some resource constraints then the access is only limited by the number of threads that can run by the underlying infrastructure. This is a system (jvm implementation + OS + machine) limitation.

---

Yep, an unsynchronized method doesn't "care" how many threads are invoking it. It's a purely passive entity and nothing special occurs when a new thread enters it.

Perhaps one thing that confuses some people is the "auto" storage used by a method. This storage is allocated on the thread's stack, and does not require the active participation of the method. The method's code is simply given a pointer to the storage.

(Many, many moons ago, it wasn't thus. Either the "auto" storage was allocated from heap when the method was called, or the method maintained a list of "auto" storage areas. But that paradigm disappeared maybe 40 years ago, and I doubt that there is any system in existence that still uses it. And I'm certain that no JVM uses the scheme.)

---

You'd have a bottleneck if one thread acquired a resource that others needed and held onto it for a long-running operation. If that isn't the situation for your method, I don't see how you'll experience a bottle.

Is this a theoretical question, or are you observing behavior in a real application that's running more slowly than you think it should?

The best answer of all is to get some data and see. Run a test and monitor it. Be a scientist.