Are singletons held in memory until the JVM is shut down?

S

Soefara

Dear Sirs,

Am I correct in understanding that once instantiated a Singleton
resides in memory until the JVM is shut down ?


For example, I have a Singleton (below) used for configuration
purposes. It simply stores all the configuration parameters for my web
application, and since it is used repeatedly on every single web page
it would be very convenient if it didn't unload from memory.

My intention is that once created, the configuration parameters will
be loaded from the database and never again discarded (until the web
application server is shut down), or until I intentionally make a call
to reloadConfig(), thereby saving me repeatedly calling the same
values from the database.

Is this what is going to happen ? Or will I actually not be making any
savings in database calls ?

Thank you very much.

Soefara.


public class Singleton {

private static Singleton theInstance = new Singleton();

private Singleton() {
// load configuration from database.
}

public static Singleton getInstance() {
return theInstance;
}

public reloadConfig() {
// reload config from database
}
}
 
X

xarax

Soefara said:
Dear Sirs,

Am I correct in understanding that once instantiated a Singleton
resides in memory until the JVM is shut down ?

No. There are rules for when an instance is
eligible for garbage collection. If your
single instance becomes eligible for GC,
then it may be collected before the JVM
shuts down.
For example, I have a Singleton (below) used for configuration
purposes. It simply stores all the configuration parameters for my web
application, and since it is used repeatedly on every single web page
it would be very convenient if it didn't unload from memory.

To prevent GC on the instance, there must be at least
one live thread that can reach the instance through a
series of strong references. The live thread need not
execute any code, it could be sleep()'ing, wait()'ing,
or join()'ing.
My intention is that once created, the configuration parameters will
be loaded from the database and never again discarded (until the web
application server is shut down), or until I intentionally make a call
to reloadConfig(), thereby saving me repeatedly calling the same
values from the database.

You example code creates a single instance and saves
the reference in a private static field. The Class object
for the class that owns the private static field must be
reachable by a live thread through a series of strong
references. When the Class object becomes unreachable by
a live thread, the corresponding class may be unloaded
by the JVM, which will make the single instance eligible
for GC.
Is this what is going to happen ? Or will I actually not be making any
savings in database calls ?
/snip/

Just keep a strong reference to the Class object that
corresponds to the class that has the reference to the
single instance (in its private static field). Be sure
that the Class object strong reference is reachable by
a live thread through a series of strong references.
 
M

Michael Borgwardt

xarax said:
You example code creates a single instance and saves
the reference in a private static field. The Class object
for the class that owns the private static field must be
reachable by a live thread through a series of strong
references. When the Class object becomes unreachable by
a live thread, the corresponding class may be unloaded
by the JVM,

Of course, this can only happen if the class was not loaded
through the standard classloader.
 
S

Soefara

Thank you for the reply, Xarax (?)
You example code creates a single instance and saves
the reference in a private static field. The Class object
for the class that owns the private static field must be
reachable by a live thread through a series of strong
references.

Sorry, what is a Strong reference versus a Weak reference ?

When the Class object becomes unreachable by
a live thread, the corresponding class may be unloaded
by the JVM, which will make the single instance eligible
for GC.

Since this Singleton is being used by JSPs and servlets,
and since a servlet always resides in memory of a Java
application server (once it has been called for the
first time), can I assume therefore that it will always
have at least one reference ?

I have been doing some testing since I first posted, and
found that the configuration parameters stored in the
static variable are never lost and do not require new
calls to the database. So, it seems to be doing what I want.

/snip/

Just keep a strong reference to the Class object that
corresponds to the class that has the reference to the
single instance (in its private static field). Be sure
that the Class object strong reference is reachable by
a live thread through a series of strong references.

Sorry, you lost me completely there :(

Soefara.
 
J

John C. Bollinger

Soefara said:
Thank you for the reply, Xarax (?)




Sorry, what is a Strong reference versus a Weak reference ?

Strong references are normal references. Java 1.2 introduced
java.lang.ref.Reference and its subclasses and related classes as a
means to retain references (Soft, Weak, and Phantom) to objects without
preventing them from being garbage collected. You will never use them
by accident.
Since this Singleton is being used by JSPs and servlets,
and since a servlet always resides in memory of a Java
application server (once it has been called for the
first time), can I assume therefore that it will always
have at least one reference ?

You are making a mistaken assumption. The servlet container is in no
way required to keep any servlet instance in memory for any particular
amount of time. Although it might be highly inefficient, a servlet
container conceivably could create a new instance for each request, and
drop the instance once request processing was complete.

Load-on-startup servlets are not special in this regard, by the way,
which makes portable use of that feature considerably less advantageous
than some developers recognize.
I have been doing some testing since I first posted, and
found that the configuration parameters stored in the
static variable are never lost and do not require new
calls to the database. So, it seems to be doing what I want.

If there is an object that must be created at webapp startup and be
retained for the lifetime of the webapp, then it should be made and
registered as a ServletContextListener, or should be instantiated and
held by such a ServletContextListener. This will make it more likely
that your app will continue to behave as you expect, rather than
possibly failing mysteriously at some point.

I cannot possibly determine what your singleton object will do without
looking at its code and the code of the objects that use it. It
conceivably could do what you describe.
Sorry, you lost me completely there :(

That's okay, it's probably unnecessary. Keeping a live reference to the
singleton _instance_ should be entirely suffcient. I outined above how
you could do so via a ServletContextListener. In point of fact, even
that may be more than you actually need to do, but call it defensive
coding and do it anyway.


John Bollinger
(e-mail address removed)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top