I have a singleton class whose instance is alive throughout the lifespan of my application. From one of the singelton instance method I am creating instance of a Runnable thread and executing it. Will the runnable thread instance become a candidate for garbage collection after its execution or will it remain in heap forever since my singleton instance is always alive?
Eg: In the example below I create a new instance of MyRunnable class each time MySingleton.getInstance().runMyThread() is called. Will these MyRunnable instances be considered for garbage colletion once done with the run() method is completely executed and over?
public class MySingleton
{
private MySingleton instance = null;
private MySingleton() {}
public static MySingleton getInstance()
{
if(instance == null)
{
instance = new MySingleton();
}
}
public void runMyThread()
{
Thread thread = new Thread(new MyRunnable()); //MyRunnable implements Runnable
thread.start();
}
}
In general an object will be a candidate for garbage collection when
it is no longer in scope and
nothing references it.
In this scenario, assuming nothing is referencing the Thread object after it finishes execution it will become a candidate for garbage collection. In your example, your singleton instances does not contain any references to the Thread object - it calls runMyThread() which creates a new Thread object and starts it. The Thread object's scope is contained to the runMyThread() method.
Related
When a thread acquires monitor lock of an object (say class B) does it acquires the monitor lock of the object belonging to it's superclass (say class A, where B extends A) ?
Observation #1 - When a thread (that owns the monitor lock of derived object B through synchronized method) calls wait() inside superclass A, the second thread acquires object B's monitor lock and goes for waiting in A. Finally, both threads exit B's object monitor at the same time.
My understanding is a thread should invoke wait() on an object whose lock it owns, else this will lead to IllegalMonitorStateException. The reason that there being no exception while wait() called inside A's instance method, does it mean the thread owning the B object lock also owns the lock of A object, it's superclass ?
Checked articles on synchronization & intrinsic locks - What does intrinsic lock actually mean for a Java class?
https://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html
public class Obs2 {
public static void main(String[] args) {
A a = new B();
Thread t1 = new Thread(a);
Thread t2 = new Thread(a);
t1.start(); t2.start();
}
}
class A implements Runnable {
public void run() {
try {
wait(2000); // OK; No IllegalMonitorStateException
} catch (InterruptedException e) {}
}
}
class B extends A {
#Override
public synchronized void run() {
super.run();
}
}
Observation #2 - When a thread (that owns monitor lock of object A through synchronized method) invokes wait() inside any arbitrary class C, it raises an IllegalMonitorStateException.
This suggests the thread calls wait() on C's object whereas it owns the lock for object A which are different. Hence the exception.
public class Obs2 {
public static void main(String[] args) {
A a = new A();
Thread t1 = new Thread(a);
Thread t2 = new Thread(a);
t1.start(); t2.start();
}
}
class A implements Runnable {
public synchronized void run() {
(new C()).display(this);
}
}
class C {
public void display() {
try {
wait(2000); //--> will lead to IllegalMonitorStateException
} catch (InterruptedException e) {}
}
}
Why this inherent discrepancy in the way the object monitor lock behaves for superclass in comparison to any other class ?
Is my understanding regarding object monitor lock missing anything?
I'm not exactly sure if your question makes any sense. There's no such thing as a "superclass" instance because the instance of the subclass is one and the same as the instance of its superclass, otherwise you would be instantiating several objects each time you use the new keyword. That is also the reason why you can't do something like:
synchronized (super) {
}
Ultimately, the ability to use wait and notify[All] belongs to Object (as they are final methods), which is the super-super class of every class. You can think of synchronizing on this as synchronizing on the monitor belonging to Object, as intrinsic locks are associated with objects, not classes (an important distinction is that an intrinsic lock associated with a Class object may be acquired).
Therefore, since both A and B are the same instance of Object, it doesn't matter that you've synchronized in B and call wait from A, they are both referring to the same Object.
There is a Windows.Forms.Timer in my project. In the Timer.Tick Method Handler I create an instance of Manager class (My Own Class) And In Manager Constructor I create some threads and store them in a dictionary. The dictionary located in a class named TransManager which implemented with singleton pattern.
public class TransManager {
private static volatile TransManager _Instance;
public static TransManager Instance
{
get
{
lock (syncRoot)
{
if (_Instance == null)
_Instance = new TransManager();
}
return _Instance;
}
}
}
I implemented the class TransManager because I need to have all created threads which produced from different instance of Manager class in same place.
The problem is when a new instance of Manager adds threads in the dictionary the last threads are gone!
Note: When I create All threads within an instance of Manager class then all thread can share the dictionary safe. According to this can I say it is possible to singleton across threads?
I checked; There is no Dictionary.Clear() in my code!
I hope the problem was clear! Ask me if it is not.
Thank you.
Looking at the IDisposable pattern + Finalizer pattern, there is something I don't understand:
public class ComplexCleanupBase : IDisposable
{
private bool disposed = false; // to detect redundant calls
public ComplexCleanupBase()
{
// allocate resources
}
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
// dispose-only, i.e. non-finalizable logic
}
// shared cleanup logic
disposed = true;
}
}
~ComplexCleanupBase()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
}
From my understanding the pattern should be implemented like above.
1) Calling Dispose() fires GC.SuppressFinalize(this), which means that the object should not be put on the finalizer queue as its already properly disposed? That helps to free up the object faster?
2) But what if I am not calling Dispose() on this object at all? In that case the finalizer should kick in, correct? But Dispose(false); does absolutely nothing (only setting disposed = true). Is this intended? It feels like as if something is missing...
Question 1: Yes, if GC.SuppressFinalize is not called the object will be placed on the finalizer queue AND will move up a generation (if not already gen 2), which means that the memory for that object will not be reclaimed until the next pass of GC for the new generation.
Question 2: Your comment //shared cleanup logic is where the shared cleanup logic will go, this is where things other than setting disposed = true would happen.
Also, an aside: if your dispose logic should only be called once, consider acquiring a lock, an uncontested lock is very fast in .Net:
public class ComplexCleanupBase : IDisposable
{
private volatile bool disposed = false; // to detect redundant calls
private readonly object _mutex = new object();
protected virtual void Dispose(bool disposing)
{
if (!Monitor.TryEnter(_mutex))
{
// We're already being disposed.
return;
}
try
{
if (!disposed)
{
if (disposing)
{
// dispose-only, i.e. non-finalizable logic
}
// shared cleanup logic
disposed = true;
}
}
finally
{
Monitor.Exit(_mutex);
}
}
... other methods unchanged
}
If Dispose(false) isn't going to do anything, that's a very good indication that neither your class nor any class derived from it should include a C#-style "destructor" nor override Finalize, and the "disposing" argument should be regarded as a dummy whose purpose is to give the protected Dispose method a different signature from the public one.
Note that implementing a destructor or overriding Finalize in a derived class, when the parent class is not expecting such behavior, can produce Heisenbugs. Among other things, the GC can sometimes decide that a class object has been abandoned, triggering its finalizer/destructor, even while an entity referred to by a field of the class is being used. For example, suppose a static class usbThingie manipulates USB controllers using integer handles, and a wrapper class usbWrapper does something like:
UInt32 myHandle;
void sendData(Byte data[])
{
UsbThingie.send(myHandle, data[0], data.Length);
}
If a sendData() call is the last thing done to an instance of usbWrapper before it is abandoned, it would be possible for the garbage-collector to observe that once UsbThingie.send() is called--even before it returns--no further references will exist to the usbWrapper, and thus it can safely trigger the finalizer. If the finalizer tries to close the channel referred to by myHandle, that might disrupt the transmission that was taking place; if usbThingie isn't thread-safe, there's no telling what might happen.
class MyClass
{
private static MyClass obj;
public static MyClass getInstance()
{
if(obj==null)
{
obj = new MyClass();
}
return obj;
}
In the above java code sample, because obj is a static variable inside the class,
will getInstance still be non-thread safe? Because static variables are shared by all threads, 2 simultaneous threads shall be using the same object. Isnt it?
Vipul Shah
Because static variables are so widely shared they are extremely un-thread safe.
Consider what happens if two threads call your getInstance at the same time. Both threads will be looking at the shared static obj and both threads will see that obj is null in the if check. Both threads will then create a new obj.
You may think: "hey, it is thread safe since obj will only ever have one value, even if it is initialized multiple times." There are several problems with that statement. In our previous example, the callers of getInstance will both get their own obj back. If both callers keep their references to obj then you will have multiple instances of your singleton being used.
Even if the callers in our previous example just did: MyClass.getInstance(); and didn't save a reference to what MyClass.getInstance(); returned, you can still end up getting different instances back from getInstance on those threads. You can even get into the condition where new instances of obj are created even when the calls to getInstance do not happen concurrently!
I know my last claim seems counter-intuitive since the last assignment to obj would seem to be the only value that could be returned from future calls to MyClass.getInstance(). You need to remember, however, that each thread in the JVM has its own local cache of main memory. If two threads call getInstance, their local caches could have different values assigned to obj and future calls to getInstance from those threads will return what is in their caches.
The simplest way to make sure that getInstance thread safe would be to make the method synchronized. This will ensure that
Two threads can not enter getInstance at the same time
Threads trying to use obj will never get a stale value of obj from their cache
Don't try to get clever and use double checked locking:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Good explanation can be found here:
http://en.wikipedia.org/wiki/Singleton_pattern
The wiki article highlights various thread-safe approaches along with some of their pros and cons.
in this case getInstance() is not thread-safe, even if you use static variable. only synchronization makes this thread-safe.
The following example shows a weird thread save modified single ton pattern which supports generics as well.
To have it just thread save and synchronization save just take the synchronized block and the transient and volatile keywords.
Notice, that there is a double check, the synchronized block is inside an if. This brings more performance, because synchronized is expensive.
Of course for a real singleton do not use maps, I said it is a modified one.
public class Edge<T> {
#SuppressWarnings({"unchecked"})
private static transient volatile HashMap<Object,HashMap<Object, Edge>> instances = new HashMap<Object, HashMap<Object,Edge>>();
/**
* This function is used to get an Edge instance
* #param <T> Datatype of the nodes.
* #param node1, the source node
* #param node2, the destination node
* #return the edge of the two nodes.
*/
#SuppressWarnings({"unchecked"})
public static <T> Edge<T> getInstance(T node1, T node2){
if(!(instances.containsKey(node1) && instances.get(node1).containsKey(node2))){
synchronized (Edge.class) {
if(!(instances.containsKey(node1) && instances.get(node1).containsKey(node2))){
Edge<T> edge = new Edge<T>(node1, node2);
if(!instances.containsKey(node1)){
instances.put(node1, new HashMap<Object, Edge>());
}
instances.get(node1).put(node2, edge);
}
}
}
return (Edge<T>)instances.get(node1).get(node2);
}
public class Singleton{
private static transient volatile Singleton instance;
public static Singleton getInstance(){
if(instance==null)synchronized(Singleton.class){
if(instance==null){
instance = new Singleton();
}
}
return instance;
}
private Singleton(){
/*....*/
}
}
Page 182:
http://books.google.com/books?id=GGpXN9SMELMC&printsec=frontcover&dq=design+patterns&hl=de&ei=EFGCTbyaIozKswbHyaiCAw&sa=X&oi=book_result&ct=result&resnum=2&ved=0CDMQ6AEwAQ#v=onepage&q&f=false
Think this can be tagged as answered now.
class MyClass
{
private static MyClass obj;
private MyClass(){
// your initialization code
}
public static synchronized MyClass getInstance()
{
if(obj==null)
{
obj = new MyClass();
}
return obj;
}
I'll agree with #Manoj.
I believe the above will be one of the best methods to achieve singleton object.
And synchronization makes the object thread safe.
Even, it's static :)
[ThreadStatic]
private static Foo _foo;
public static Foo CurrentFoo {
get {
if (_foo == null) {
_foo = new Foo();
}
return _foo;
}
}
Is the previous code thread safe? Or do we need to lock the method?
If its ThreadStatic there's one copy per thread. So, by definition, its thread safe.
This blog has some good info on ThreadStatic.
A [ThreadStatic] is compiler/language magic for thread local storage. In other words, it is bound to the thread, so even if there is a context switch it doesn't matter because no other thread can access it directly.