I have been going through this tutorial and from what I understand, a singleton class can only be initialized once. Therefore I wrote the following 1 line of code:
public synchronized static DefaultHttpClient getThreadSafeClient {
**System.out.println("this should only happen once!!");**
I then wrote the following lines of code in my MainActivity's button:
HttpClient httpclient = multithreaded_httpclient.getThreadSafeClient();
HttpClient httpclient1 = multithreaded_httpclient.getThreadSafeClient();
I then pressed the button many times and to my surprise i found this in my logcat:
this should only happen once
this should only happen once
this should only happen once
this should only happen once
I thought singleton classe's method only executes once... how is this possible ?
It seems there is a small misunderstanding related to Singletons.
Singletons can only be initialized once, meaning there can only be one instance of it. Of course, the static method will be executed each time you call it, but the returned instance will always be the very same one.
In a nutshell, the Singletons pattern means that:
The constructor of your class is private
You create a public factory method, where YOU take care of:
If it is the first time that an instance is requested, create an instance with new YourClass()
If an instance was already created in a previous call, you don't create a new one, but return the previous one.
So, when any other class needs an instance of that class, they are enforced to call that factory method, since the constructor is private, and inside of that method, you write the code to ensure there is only one instance.
Thats all. With this only one object can be created, so all the possible instances of the object are actually the same, but of course any call to any public method of that object will be normally executed, no matter how many times it is called.
Related
Sorry for the bad title, but the explanation will be very simple.
I have, on a Service on Spring this method:
private static boolean initialized = false;
#PostConstruct
public void onPostConstruct() {
synchronized (MyClass.class) {
if (!initialized) {
// do some init
startThread();
initialized = true
}
}
}
JavaSE-wise, I'm 100% confident that there can't be more than one thread started by the call startThread(). It has something to do with the loading of classes in Spring, because there's more than one thread. I see it in the logs.
I cannot reproduce the bug on my computer, only on the server, and I don't have access, so, I ask here. If someone can float me some light! thanks
Your code is definitely thread safe. Multiple calls to startThread() will only possible be if your class is loaded more than ones by different ClassLoaders.
I'm not a Spring expert but according to the answers of this question it is possible to specify a ClassLoader for each ApplicationContext. If your class should be used in multiple ApplicationContexts with different ClassLoader instances it would be possible, that there exist two class objects for your class. Since you synchronize by the class object, calls to onPostConstruct() would only be mutually exclusive for one instance of the class.
To verify that your code is called for multiple instances of the class, extend your code with some logging and log the return value of MyClass.class.getClassLoader().
During execution, static variable value are initialised to class but not instance, so if you have a any one instant of your Service changed the initialized to true, then it changed to true forever for all instance.
for #PostConstruct, it will be called when the constructor is called, and for Spring server, all the class will be constructed as bean during startup, so this method should be called once, so before the start of service, the flag already changed to true.
I suggest you to create an other method to change the flag rather than in post construct.
I guess the issue with the order of execution between startThread() method and the reassignment of initialized variable.
First Execution: startThread() method, is it starting a thread ??
at the same time initialized reassigned to true;
Is there something that I can do to simulate "on created" event?
I have a base class which other people can extend, and currently I have an init() that will initialize the instance, but it should be called only after the constructor stack completes.
If I call init() in the base class' constructor, then I might potentially initialize wrongly, because the subclass' constructor has not finished executing. The subclass can initialize values of some of the protected fields, which would have an impact on how init() initializes the instance.
My current approach is to make init() protected final, and asks that subclasses must call it at the end of their constructor. This approach works, but only provided if subclasses really do follow the instruction.
Edit
I thought I would give some extra information. This is part of a JavaFX project/custom API. So I had tried using Platform.runLater(() -> init()), which was a major mistake. Platform.runLater() would only run after the whole execution stack completes, which causes the usage of uninitialized instance in this case:
Foo instance = new Foo();
instance.doSomething();
There is no easy way to force a method call in the end of subclass constructor. This may be doable via annotation processor, which let you modify source code at precompile time. But it will be complicated. I think instead of subclassing, your goal can be better achieved using factory pattern instead.
You can define a few setters to let users initialize your fields, then call init in the end of your factory method.
public class MotoXCellPhone {
//assume there's a speaker class
private BlueToothSpeaker speaker;
//why instantiate in constructor?
MotoXCellPhone() {
speaker = new BlueToothSpeaker();
}
//or if i instantiate in a method?
public BlueToothSpeaker useSpeaker() {
speaker = new BlueToothSpeaker();
return speaker;
}
}
why would i want to instantiate a class in another class' constructor? i don't fully understand composition yet so i'm fuzzy on the 'why" of everything
If you instantiate it in the method, you'll create a new one each time that method is called. If that doesn't make sense -- if you want one BlueToothSpeaker object to be tied to the MotoXCellPhone object for its lifetime -- then you need to create it (or inject it) in the constructor.
The argument is as follows: if someone else uses your code, they might not call useSpeakser() and thus speakers might be null. Instantiating speakers within the constructor asserts that it will not be null.
The constructor will run and instantiate BlueToothSpeaker right when MotoXCell is instantiated, whereas the method will only instantiate the new class when it is called.
There are two types of member initialization, each with pros and cons, I'll try to enumerate them:
early-initialization:
done when declaring the member, or within the class constructor
pros:
the created object begins it's lifecycle at the same time as it's "parent", and is available at any time without needing to do any checks
in the case of a worker class, the created object can start working right away
cons:
more CPU/memory used for that object
depending on the context the object might never be used
lazy-initialization:
done on demand, usually within its getter
pros:
the object will be created only when firstly needed, thus reduces its CPU/memory usage
no context dependent, if the member is not needed at all, it will not be created
cons:
you will need to always access the member via it's getter within the "parent" class, otherwise you might run into crashes
care must be taken when dealing with multithreading (e.g. a lock must be used), and this has a performance impact
Depending of the implementation of your class you might choose one over another.
I am not looking for what is a singleton. There are hundreds of links out. I have not found good examples of client of singleton. Example consider a Singleton class ( whose internals are not important at all)
I want to use this object. Where / how woud client use it ? Should it be used in a constructor ? static initializer ?
Singleton tmp = Singleton.getInstance( );
I would appreciate any sample examples of singleton clients ??
The Singleton Pattern is when you create an object that is designed that there be a single instance of that object in the program. As a client, you have to get a pointer to an instance. You have only four options:
Hold a reference in a static variable and initialize by 'lazy evaluation' that is, test for null, and then initialize when null. After that the value is set.
Hold a reference in a static variable and initialize at static initialization time. Are you sure that the singleton it ready at that time? This is a concern.
Hold reference in local variable, and initialize every time with call to getInstance().
Don't use a variable at all and call in the method chain. If only one reference for one call is needed, this is fine.
In general, getInstance should be quite efficient, and there should be little reason to hold a copy of the reference in your own static. In a sense, your static is duplicating the job of the singleton class which also has to have a static. A single shouldn't ever change, but if it ever did, you would be left holding a stale reference. Option 4 is OK if you need only one call, but this pattern encourages inefficiency when multiple calls are needed. So, for all these reasons I believe you should use option 3 and get the instance every time.
There are times that this singleton pattern is appropriate. There are also times that it is not appropriate, and a class with static methods is more efficient. How can you tell when and when not to use the Singleton pattern? Here is a blog post I made last week on the subject:
http://agiletribe.purplehillsbooks.com/2013/10/08/dont-abuse-singleton-pattern/
public class Factoryclass
{
public static MyClass returnObject(String str)
{
// Based on the parameter passed it will retrn some class
}
}
If in a Web Application , theer were 100 requests .
Now please tell me how many objects of Factoryclass will be created ??
if you do
Factoryclass.returnObject()
no Factoryclass instances will be created, unless you do new Factoryclass() inside the returnObject method
It entirely depends on the content of your method returnObject(). The fact that it's a static method only means that it is "stateless" and doesn't pull from non-static instance members in order to work. However, you could potentially instantiate a new instance with each and every time it has been called.
The fact that it's a factory leads me to think that is, in fact, the case. However, the nature of the factory pattern would suggest that it should not matter to you whatsoever. If your implementation depends on the fact that this Factoryclass returns multiple instances or the same instance, someone made a wrong decision in making it a factory.