 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / November 2007Singleton and performance
What is the behavior/performance in concurrent access environment for the following: SingletonClass { //no state. Only its own instance. method() { //do this //do that //send request to a queue //read from dynamic queue //return data } } NormalClass { //some member variables method() { //do this //do that //send request to a queue //read from dynamic queue //return data } } Scenario 1: --------------- SomeClass { some method() { SingletonClass s = SingletonClass.getInstance(); Data data = s.method(); } } Scenario 2: --------------- SomeClass { some method() { NormalClass s = new NormalClass(); Data data = s.method(); } } Assumption: the method that reads data from queue can take a while to finish. Each queue request results response in a dynamic queue. Will Singleton cause a performance bottleneck by serializing execution? > What is the behavior/performance in concurrent access environment for > the following: [quoted text clipped - 46 lines] > Will Singleton cause a performance bottleneck by serializing > execution? The singleton you've shown does not automatically serialize execution any more or less than the normal class, presuming that the contents of the method () are the same. Now if SingletonClass.method had a "synchronized" keyword on it, that would be different. Matt Humphrey http://www.iviz.com/ On Nov 28, 8:53 am, sen...@gmail.com wrote: > What is the behavior/performance in concurrent access environment for > the following: [quoted text clipped - 50 lines] > Will Singleton cause a performance bottleneck by serializing > execution? With the structures above, none of the approaches appear thread-safe. To achieve thread safety, you will need to synchronize the method, or synchronize on an object's lock in the code fragment that needs to be thread safe. Thread safety will cause a performance bottleneck in multi-threaded environment as it impacts concurrent execution. -cheers, Manish > On Nov 28, 8:53 am, sen...@gmail.com wrote: >> What is the behavior/performance in concurrent access environment for [quoted text clipped - 57 lines] > thread safe. Thread safety will cause a performance bottleneck in > multi-threaded environment as it impacts concurrent execution. The "queue" could be a class from java.util.concurrent such as <http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html> This might obviate the need for 'synchronized'. Concurrent programs don't have to experience "a performance bottleneck" to be safe. If that were the case, there'd be no use case for concurrent programming. In fact, well-designed thread-safe concurrent code will increase performance in many cases. Even more importantly, it can decouple application modules from each other, and actually reduce the chance for bugs. Assuming you do program with thread safety in mind, of course. Use of API classes such as ConcurrentLinkedQueue simplifies one's job and decreases risk because we're using standard and (presumably) robust libraries.  SignatureLew > What is the behavior/performance in concurrent access environment for > the following: [quoted text clipped - 12 lines] > } > } Assuming that the method() itself doesn't need synchronisation, (if it does, then the following is moot) you get to compare these two alternatives: the new-operator for NormalClass versus SingletonClass.getInstance() In a multithreaded environment you usually need some synchronisation for implementing the Singleton-pattern itself. (the decision of whether the class is already instanciated or if that needs to be done now, must be synchronized, or you may end up with more than one such class created and only one of those saved for future reference.) Now that I think this through and based on your alternative of not singleton'ing at all, that might be not that bad afterall. If your intention is just to keep the number of instances "low" (but not necessarily one), then an unsecured getInstance() might give overall best performance (though I wouldn't call it anything like Singleton then). If you want a real SingletonClass, it might turn out more expensive than creating a new instance for every use. I hope I understood the question correctly, since I understood it differently than the other three followups I saw before. Let me ask you one question, If the SingletonClass doesn't have state why do you think it would read synchronization? First analyse the need for synchronization. A good way to start is to identify the variables that are accessed by multiple threads. Regards, Ravi. On Nov 29, 4:19 am, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote: > sen...@gmail.com <sen...@gmail.com> wrote: > > What is the behavior/performance in concurrent access environment for [quoted text clipped - 38 lines] > I hope I understood the question correctly, since I understood it > differently than the other three followups I saw before. > Let me ask you one question, > If the SingletonClass doesn't have state why do you think it would > read synchronization? > First analyse the need for synchronization. A good way to start is to > identify the variables that are accessed by multiple threads. Well, the implementation of GetInstance wasn't specified, so I assumed that the indeed necessary variable needed to implement it was just forgotten/omitted to mention, or it may even have used a static variable of another class... If you know of a getInstance()-implementation in the context of SingletonClasses, that does *not* require *some* variable to hold that one instance, then please let me know, and I'll thankfully apologize for having made such a bold assumption. PS: Because the answer ends up to be before the question. Why? Please don't top-post! > Let me ask you one question, > If the SingletonClass doesn't have state why do you think it would > read synchronization? > First analyse the need for synchronization. A good way to start is to > identify the variables that are accessed by multiple threads. A stateless class may still need synchronization if the methods it calls in other classes have state. In the original example it's impossible to tell if method () requires synchronization, but since the OP's question was about performance rather than correctness I think it's fair to assume synchronization is not needed, particularly because the method () body is intended to be the same for both. Given that the OP asked about "serializing execution" when there's no apparent synchronization suggests to me that both methods might have been (or were supposed to have been) marked synchronized. In that case the singleton version would very likely be slower because it is synchronizing on only one instance whereas the others synchronize on distinct instances. Of course, synchronizing on distinct objects would be pointless because it would mean that no synchronization is really needed. Synchronization could be used to protect the state of NormalClass, but because the code of the method() is the same for both classes it would not be using any of that state and so would not need to be synchronized. Matt Humphrey http://www.iviz.com/ > > Let me ask you one question, > > If the SingletonClass doesn't have state why do you think it would [quoted text clipped - 4 lines] > A stateless class may still need synchronization if the methods it calls in > other classes have state. Thats true.. From the given code its not trivial, but I mentioned to identify variables that are accessed by multiple threads. This also includes references of any local variables that can escape the method. In the original example it's impossible to tell > if method () requires synchronization, but since the OP's question was about > performance rather than correctness I think it's fair to assume [quoted text clipped - 10 lines] > classes it would not be using any of that state and so would not need to be > synchronized. Assuming Synchronization is necessary, I really don't see any performance difference between a single object vs. single ton (from my understanding of Java Language). > Matt Humphreyhttp://www.iviz.com/ Thanks, Ravi <snip> > Assuming Synchronization is necessary, I really don't see any > performance difference between a single object vs. single ton (from my > understanding of Java Language). There isn't. But the OP's example isn't dealing with a single object. In the NormalClass case he's creating a new object for each invocation of method(). Each different invocation of method () will be essentially unsynchronized even if the method itself *is* synchronized because they're locking on different monitors. There could be multiple instances of method() in parallel operation (so we certainly have to expect that the whatever they call will be properly synchronized) In the singleton case only one method will proceed at a time (serialized execution) because they all block on the same monitor. Matt Humphrey http://www.iviz.com/ > In the singleton case only > one method will proceed at a time (serialized execution) because they all > block on the same monitor. This is true indeed, but only under the assumption that the class (or the method()) itself is declared as synchronized, which I don't remember to have seen from the OP. If the class or method is *not* itself synchronized, then the Singleton- ness will not prevent the method from being executed concurrently. even if the getInstance() was synchronized, even then method still could be concurrently executed. In the particular case that method() really doesn't need any synchronisation, and a pseudo-Singleton Pattern suffices, then that is likely faster than both the real Singleton and the "new- class-each-go" approach. >> In the singleton case only >> one method will proceed at a time (serialized execution) because they all [quoted text clipped - 3 lines] > (or the method()) itself is declared as synchronized, which I don't > remember to have seen from the OP. Yes, I was speculating in a prior message that the OP's singleton example had omitted the synchronization keyword. The question about serialized execution doesn't seem to make sense without it, but there's no evidence that it's actually needed. Matt Humphrey http://www.iviz.com/ Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.