Concurrent invocation of a singletone method

[Jonah Kommu]

Say there is a method in my singleton.
And, from my handler there are invocations to this method.

my question is if there are 1000 concurrent hits to the singleton method, how is the situation handled, singleton being only one instance in the memory?

- will the 1000 requests queued to be handled in sequence by the JVM
- or will the virtual machine spawn 1000 threads

Thank You for your response.

[Matthew Brown]

Hi Jesse. Welcome to The Ranch!

The only way your singleton can have 1000 concurrent hits is if there are already 1000 threads. If all the calls are in the same thread then they have to happen in series just like everything else that happens in a single thread.

Assuming you have 1000 threads calling the method at the same time, they can all be processed "at the same time" (subject to limitations of the processor, etc), unless the method is synchronized. If it is, then all the calls must happen one after the other.

Does that answer make sense?

[Jonah Kommu]

Thanks for your quick reply.

Yes there are 1000 threads calling the method (that is within a singleton) at the same time.
But singleton being only one instance in memory, wouldn't 1000 threads get queued for the access ?

Do let me know if my question is not clear.

Thanks

[Matthew Brown]

Only if the singleton was synchronized - either explicitly by you or possibly by the container if it's running as an EJB or something like that. By default, there's nothing stopping multiple threads running the same method at the same time.

[Pat Farrell]

Since its widely known that "Singletons considered dangerous", why are you having 1000 threads beat on a singleton? Perhaps one can argue that a singleton is acceptable for near-constant data, but why are you calling methods in the singleton?

There are far better patterns to use than a singleton, such as a factory that only creates one instance.

[Jonah Kommu]

Pat Farrell wrote:Since its widely known that "Singletons considered dangerous", why are you having 1000 threads beat on a singleton? Perhaps one can argue that a singleton is acceptable for near-constant data, but why are you calling methods in the singleton?

There are far better patterns to use than a singleton, such as a factory that only creates one instance.

Actually we are using Factory that creates one instance. (And I assume my referring it as a singleton is wrong??)

And within the one instance object's method, static variables are not referred and only local variables are being used.
So I think we are good.

Also would you please explain what you meant
There are far better patterns to use than a singleton, such as a factory that only creates one instance

T.I.A

[Pat Farrell]

The term Singleton usually means a static object that has global scope. Or one that is used statically, with code similar to
Calendar cal = Calendar.getInstance();

Using a singleton this way makes it essentially a global wad of static data and methods, and it makes proper unit testing impossible. Every class that uses any part of the data in the singleton is closely coupled to the detailed implementation. It created implicit dependencies that break the whole concept of unit testing. All of this is separate and distinct from your performance bottleneck concerns.

A much better design is to have a factory return an instance, so that for testing, you can return a mock instance that just addresses the needs of the specific unit under test.