While designing a service class should it be singleton in java? Generally DAO is made singleton, so should the calling Service class be made singleton also?
3 Answers
IMHO yes, services should not hold state and should therefore be made singleton.

- 15,454
- 8
- 66
- 101
-
Now if you make it singleton we are hitting the performance in case the application is request intensive i.e there is large number of hit for the service class – Jyotirup Dec 29 '11 at 16:11
-
3@Jyotirup Using a singleton properly will not impact performance (if anything it will improve it) – Peter Lawrey Dec 29 '11 at 16:19
-
@Peter Making it singleton will have the effect that there is just one instance of this class to service all my request. So now if I have 10 request for the service class, it will service the requests sequentially so there will be a delay in service... performance hit if I scale up number of request – Jyotirup Dec 29 '11 at 16:24
-
6@Jyotirup: That's wrong, you mix up threads and objects... Synchronization is a different topic. – home Dec 29 '11 at 16:27
-
@Peter: Even though they are different topics, if application is multi threaded, shouldn't singleton class designed in thread safe way? which ultimately lead to performance issue. Isn't it? – kosa Dec 29 '11 at 16:32
-
@Jyotirup That is true if your Singleton is single threaded with a single lock. If you Singleton is concurrent, it solves this problem. – Peter Lawrey Dec 29 '11 at 16:37
-
2@thinksteep, My feeling is that singletons should be practically stateless and there for thread safe. – Peter Lawrey Dec 29 '11 at 16:38
-
1@home Like Peter pointed out, I was meaning in a multi threaded application we will face the issue – Jyotirup Dec 29 '11 at 16:39
-
1@Peter, I agree that singletons should be stateless, but when you are designing singleton for a service, can we really implement as stateless? – kosa Dec 29 '11 at 16:42
-
@Jyotirup If you want multiple threads to be able to use Singleton at once, you need to ensure it can be used concurrently. – Peter Lawrey Dec 29 '11 at 16:48
Singletons are bad, if you develop them. If you are using dependency injection, let the DI container handle the singleton nature of your Service object. If you are not using dependency injection, use a static method instead of a singleton.
Classic example of bad:
public class HootUtility // singleton because developer was a goofball.
{
...
public void blammy(...) { ... }
public HootUtility getInstance() { ... }
}
... somewhere in the code.
HootUtility.getInstance().blammy(...); // This is silly.
Better implementation of the above:
public class HootUtility // Not a singleton because I am not a ______. (fill in the blank as you see fit)
{
// You can limit instantiation but never prevent instantiation.
// google "java reflection" for details.
private HootUtility()
{
throw new UnsuppotedOperationException();
}
public static void blammy(...) { ... }
}
... somewhere in the code.
HootUtility.blammy(...);
If you have a service interface that has an concrete implementation, use a dependency injection framework to inject the implementation (DI frameworks include: spring and guice).
Edit: If I was using spring, I would choose singleton scope (the default).

- 37,124
- 11
- 56
- 82
-
Interesting approach about throwing exception in constructor. Personally I just left it blank. Do you actually do it in your production code? – Stan Kurilin Dec 29 '11 at 16:25
-
-
1In general I agree with you. Nevertheless, option #1 is a reasonable solution if the object (singleton) has to maintain internal state. – home Dec 29 '11 at 16:31
-
@Jyotirup In Spring community it's common to make it Singleton since it's default scope. In Guice - no scope or "prototype". See my answer for some extra notes. – Stan Kurilin Dec 29 '11 at 16:32
-
@StasKurilin So in a multi threaded application making it singleton will hit on the performace? – Jyotirup Dec 29 '11 at 16:38
-
In a multi-threaded application singleton seems reasonable; but I suggest a DI framework will be better. just be sure to synchronize either the methods or appropriate sections of code. – DwB Dec 29 '11 at 16:40
No
Actually I believe you shouldn't care about it while design. Like @DwB mentioned DI framework should do this job. Furthermore I believe no scope ("prototype") should be default and I don't see anything bad if somebody will create it itself. Also that issue can be simplified by modularization and separating service interface and implementation like best practices told as to do.

- 15,614
- 21
- 81
- 132
-
-
@Jyotirup I don't think so. If they are state free you can change and you are using DI properly you can change it easily whenever you want. – Stan Kurilin Dec 29 '11 at 16:49
-
1I'd say it would be a bad approach to prototype. Think about if you're making thousands of requests on your web app, or even just hundreds. That's hundreds of instances of a class being initialized. Conceptually, if the creation of the class and its dependencies (eg. dao prototypes with db connections) is expensive enough, prototyping services could lead to thrashing faster, especially in the event of a DDoS. Singletonned services with a DI framework like Spring's @Autowired would cut down on some unnecessary resource allocation – user3466773 Dec 26 '17 at 09:41