package singleton;
public class SingletonClass {
private static SingletonClass singleton = null;
private SingletonClass() {
}
static boolean stopThread = true;
//approach 1 which fails in multithereaded env
/*public static SingletonClass getInstance(){
if(null == singleton){
try {
if(stopThread){
stopThread = false;
Thread.sleep(1000);
}
} catch (InterruptedException e) {
e.printStackTrace();
}
singleton = new SingletonClass();
}
return singleton;
}*/
//approach 2 which works
//method is synchronized
/* public static synchronized SingletonClass getInstance(){
if(null == singleton){
try {
if(stopThread){
stopThread = false;
Thread.sleep(1000);
}
} catch (InterruptedException e) {
e.printStackTrace();
}
singleton = new SingletonClass();
}
return singleton;
}*/
***//approach 3 which is failing but I don't understand why
//big block of code is synchronized
public static SingletonClass getInstance(){
if(null == singleton){
synchronized (SingletonClass.class){
try {
if(stopThread){
stopThread = false;
Thread.sleep(1000);
}
} catch (InterruptedException e) {
e.printStackTrace();
}
singleton = new SingletonClass();
}
}
return singleton;
}***
//small block of code is synchronized, checked null again because even object instantiation is synchronised
//if we don't check null, it will create new object once again
//approach 4 which works
/* public static SingletonClass getInstance(){
if(null == singleton){
try {
if(stopThread){
System.out.println("in thread...");
stopThread = false;
//even if we interchange above 2 lines it makes whole lot of difference
//till the time it takes to print "in thread"
//2nd thread reaches there n enters if(stopThread) block because
//stopThread is still true because 1st thread spent time in writing that sentence and
//did not set stopThread = false by the time 2nd thread reached there
Thread.sleep(1000);
}
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (SingletonClass.class){
System.out.println("in this block");
if(null == singleton){
singleton = new SingletonClass();
}
}
}
return singleton;
}*/
}
---------------------------------------------------------
package singleton;
public class ThreadUsage implements Runnable {
#Override
public void run() {
SingletonClass singletonOne = SingletonClass.getInstance();
System.out.println(singletonOne.hashCode());
}
}
----------------------------------------------------------------
package singleton;
class ThreadUsageTest {
public static void main(String[] args) {
Runnable runnableOne = new ThreadUsage();
Runnable runnableTwo = new ThreadUsage();
new Thread(runnableOne).start();
new Thread(runnableTwo).start();
}
}
---------------------------------------------------------------------------
In approach 3, it's not giving same hashCode for 2 objects, I've kept both Thread.sleep as well as object instantiation under synchronised block so what I'm thinking is , 2nd thread should not even enter this block until 1st finishes, but it's still doing and creating 2nd object leading to diff hashCode. What am I mssing here? Could someone correct my understanding here ? If I check for null b4 object creation then it's working as expected but why would I need to check null again here because my entire code is under synchronised block?
if(null == singleton)
singleton = new SingletonClass();
Here's one way that code (approach 3) ends up creating and returning two (or more) separate objects for the singleton:
Thread A enters the function and sees null for singleton
Thread B enters the function and sees null for singleton
Thread A enters the synchronized block
Thread B waits because it can't enter the synchronized block
Thread A assigns to singleton
Thread A exits the synchronized block
Thread A returns one object
Thread B enters the synchronized block
Thread B assigns to singleton
Thread B returns a different object
E.g., there's a gap between the null check and entering the synchronized block that follows it.
To solve it, just make getInstance a synchronized method and remove the synchronized block inside it:
public static synchronized SingletonClass getInstance() {
if (instance == null) {
singleton = new SingletonClass();
}
return singleton;
}
Or if you really want to avoid synchronization on subsequent calls, on Java 5 or later (which hopefully you're using!), declare singleton volatile and check again within the synchronized block:
private static volatile SingletonClass singleton;
// ...
public static SingletonClass getInstance() { // Only works reliably on Java 5 (aka 1.5) and later!
SingletonClass instance = singleton;
if (instance == null) {
synchronized (SingletonClass.class) {
instance = singleton;
if (instance == null) {
singleton = instance = new SingletonClass();
}
}
}
return instance;
}
That's the double-checked locking idiom. In Java 4 (aka 1.4) and earlier that wasn't necessarily reliable, but it is now (provided you use volatile on the member).
In a comment user2683814 asked a good question:
Could you explain the assignment to local variable before null check in the second code snippet ? Checking the class variable directly won’t work ?
Yes, it would work, but less efficiently.
In cases where singleton is non-null, using a local means the method only accesses singleton once. If the code didn't use a local, it would access singleton at least twice (once to check it, once to return it). Since accessing a volatile variable is slightly expensive, better to use the local (which in the code above can be optimized into a register).
That may seem like premature micro-optimization, but if you weren't doing this in performance-critical code, you'd just make the method synchronized and avoid the complexity of double-checked locking entirely. :-)
In approach three, you do a check on the singleton variable; you do this outside of any synchronized block, which is why it doesn't work: There is no guarantee here that threads wait before checking. They all check as fast as they can, which is why 2+ threads may all see a null here, even as one of them is already at work making that instance.
You then synchronize, sure. However, that doesn't magically give this code 'only assign singleton once' powers - after all, the code in that singleton block IS going to assign a newly created instance of SingletonClass to the singleton variable.
Two relevant notes:
[1] The java memory model states that any given field is like schroedinger's cat: Each thread has a copy of it, or doesn't - up to the threading model. An individual copy is sent out to each other thread's copy, or to some of them, at arbitrary times, and the same goes for receiving updates from the others. You can't rely on this mechanism, it may not even be used, there is no way to control it (other than volatile which can help but it's a bit tricky to use correctly). The point is to write your code such that it can't matter. Once you establish 'comes before' / 'comes after' relationships between code, for example because you use a synchronized block, this arbitrary nature goes away, and you are guaranteed visibility (so if code A comes before code B, e.g. because they both synchronize on the same object and A 'won' the battle, anything A writes anywhere will be visible to B once B gets to run, guaranteed, because there is a CA/CB relationship here).
Put that null check inside and all of a sudden the problem goes away.
[2] If all you're trying to accomplish is that there is exactly one instance of SingletonClass, you're barking up the wrong tree. This is not how to do that. It is in fact TRIVIALLY simple. All you do, is this one line:
public class SingletonClass {
public static final SingletonClass instance = new SingletonClass();
private SingletonClass() {
// ensure nobody but you can call this.
}
}
That's it. You may think this means the class is initialized as your app boots, but that's not true. Classes are only loaded if some code is run that uses the class. Assuming ALL uses of SingletonClass involve getting that singleton instance (usually true), this is as good as anything. If for some bizarre reason code may interact with SC without grabbing the singleton, you can still use this mechanism, just, using an inner class:
public class SingletonClass {
private SingletonClass() {}
public static SingletonClass getInstance() {
return Inner.instance;
}
private static class Instance {
private static final SingletonClass instance = new SingletonClass();
}
}
This guaranteed does not call that constructor until someone calls getInstance(), only calls it once, CANNOT ever call it twice, and does it in the most efficient way possible.
EDIT: Formatting.
So problem was both threads can reach method at once and so both will get object as null at once before first one entering synchrosied block.
Using #rzwitserloot and #T.J. Crowder comments, I reached to conclusion that, it's not necessary to use synchronised for creating SIngleton object.
Below code can do that and it's been testing with thread tests n junits as well
package singleton;
public class SingletonClassSecond {
private static SingletonClassSecond singleton = new SingletonClassSecond();
private SingletonClassSecond() {
}
public static SingletonClassSecond getInstance(){
return singleton;
}
}
---------------------------------------------------------------------------
package singleton;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
class SingletonClassTest {
#Test
public void shouldCreateSingleton(){
SingletonClass singletonOne = SingletonClass.getInstance();
SingletonClass singletonTwo = SingletonClass.getInstance();
singletonOne.print("1");
singletonTwo.print("2");
Assertions.assertEquals(singletonOne.hashCode(),singletonTwo.hashCode());
}
}
--------------------------------------------------------------------------------
package singleton;
class ThreadUsageTest {
public static void main(String[] args) {
Runnable runnable = new ThreadUsageSecond();
Runnable runnableTwo = new ThreadUsageSecond();
Runnable runnableThree = new ThreadUsageSecond();
Runnable runnableFour = new ThreadUsageSecond();
new Thread(runnable).start();
new Thread(runnableTwo).start();
new Thread(runnableThree).start();
new Thread(runnableFour).start();
}
}
Hashcode is same for all 4 threads.
Related
1) if synchronized(this) is used, which means that any of the two threads will lock on factor instance and increment val variable value till the loop exits.
so synchronized(this) means here that we should not use any other instance variables. We have to use only the variables of factor instance inside the synchronized block?
2) if synchronized(addition) means here that we have to use only add variable not the val variable of factor instance class?
There is a big confusion regarding this synchronization block .
what i understood is synchronization block will lock on the object's instance and guard the operation and make it thread safe. But using different instance really means that it should guard only that particular instance variables not any other instance variables. Can anyone explain in depth concept regarding this relating with the code provided below
class Factor implements Runnable
{
int val = 0;
Addition addtion = new Addition();
#Override
public void run()
{
currInsLock();
diffInsLock();
}
// locking on the current instance which is this
// we will use synchronized(this)
public void currInsLock()
{
synchronized (this)
{
for(int i=0;i<100;i++)
{
try
{
Thread.sleep(100);
}
catch (InterruptedException e)
{
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName()+"---val value lock on this obj -->"+val++);
}
}
}
// locking on the different instance
public void diffInsLock()
{
synchronized (addtion)
{
for(int i=0;i<100;i++)
{
try
{
Thread.sleep(100);
}
catch (InterruptedException e)
{
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName()+"---val value lock on addition obj -->"+val++);
System.out.println(Thread.currentThread().getName()+"---add value lock on addition obj -->"+addtion.add++);
}
}
}
}
Addition class :
public class Addition
{
public int add=0;
}
The Main class
public class ConcurrentDoubt {
public static void main(String[] args)
{
Factor factor=new Factor();
Thread thread1=new Thread(factor);
Thread thread2=new Thread(factor);
thread1.start();
thread2.start();
}
}
What you use as object's monitor is not really important, it could be any object, I would even say that ideally we should never use this as object's monitor but rather a private final Object instance to better protect our class because if outside your code, we use the instance of your class as object's monitor it could prevent your class to work properly.
The key point is to use exact same object's monitor anytime you want to modify or access to anything that you want to protect (member variables, class instances...) if what you want to protect is accessed/modified outside a synchronized block or with a different object's monitor, your code is no more thread-safe because you don't prevent concurrent accesses or modifications anymore. Indeed only one thread can execute code protected by a synchronized block for a given object's monitor, so it you have 2 different object's monitors to protect the same thing, you could have 2 threads accessing/modifying what you try to protect.
So here, you use this and addtion as object's monitors to protect your member variable val so your code is not thread-safe, you need to use the same object's monitor.
Assuming that you want to use this as object's monitor to protect your member variable val, your code should rather be:
synchronized (addtion) {
for(int i=0;i<100;i++) {
...
synchronized (this) {
System.out.println(
Thread.currentThread().getName() +
"---val value lock on addition obj -->" + val++
);
}
System.out.println(
Thread.currentThread().getName() +
"---add value lock on addition obj -->" + addtion.add++
);
}
}
In the android tranning Use a Singleton Pattern
public static synchronized MySingleton getInstance(Context context) {
if (mInstance == null) {
mInstance = new MySingleton(context);
}
return mInstance;
}
I'm thinking it still not thread safey.
If Object A do getInstance and Object B do getInstance synchronously,it will still break the lock, and create two mInstance.
Because synchronized for method is only available for ONE object from different thread, but not for 2 objects.
So DO I have wrong comprehension, or below code is more safe than original?
public static synchronized MySingleton getInstance(Context context) {
synchronized(MySingleton.class)
{
if (mInstance == null) {
mInstance = new MySingleton(context);
}
}
return mInstance;
}
Your two examples do exactly the same thing.
This:
class Foobar {
static synchronized mumble(...) { doSomething(); }
}
Is just a shorthand way to write:
class Foobar {
static mumble(...) {
synchronized(Foobar.class) { doSomething(); }
}
}
A similar rule applies for non-static methods. This:
class Foobar {
synchronized mumble(...) { doSomething(); }
}
is just a shorthand way to write:
class Foobar {
mumble(...) {
synchronized(this) { doSomething(); }
}
}
I'm not sure I really understand your question, but maybe you do have "wrong comprehension".
I don't like the shortcut forms because synchronized methods draw attention away from the fact that methods are not what we want to protect with synchronization. What we want to protect is data.
We use synchronization when it is impossible for one thread to update some collection of data without creating a temporary, invalid state that other threads must not be allowed to see. We wrap a synchronized block around the code that creates the invalid state, and we also wrap synchronized blocks that synchronize on the same object around every piece of code that must not be allowed to see the invalid state.
The JVM will never allow two threads to be synchronized on the same object at the same time, so if we've done everything right, no thread will be allowed to see the invalid state except for the one that temporarily creates it.
I inherited this code from a previous developer (lol). I'm considering changing this to support a join instead of using a listener kind of callback.
My requirements:
1. I need to have the calling thread wait until the DoMath class thread has completed.
2. I need to prevent other threads from calling it.
This, in another thread (and class) - :
DoMath.getInstance().performMathCalc();
It doesn't wait or sleep of course when it calls this:
public class DoMath {
protected math calc() {
}
public static DoMath getInstance() {
if(_instance == null) {
_instance = new DoMath();
}
return _instance;
}
// perform a synchronous math calc, and return a boolean indicating success or failure.
public boolean performMathCalc() {
MathEngine.setApplicationMode(MathEngine.AUTO);
MathEngine.getInstance().StartMathCalc(MathEngine.DIVISION);
return true;
}
// perform an async math calc, and call back the listener when done
public void performMathCalc(final listener client) {
Thread mathThread = new Thread(new Runnable() {
public void run() {
boolean result = performMathCalc();
client.mathFinished(result);
}
});
mathThread.setDaemon(true);
mathThread.start();
}
public static interface listener {
public void mathFinished(boolean success);
}
protected static DoMath _instance;
}
So, is it better to just use the listener or implement a join in the calling class?
Do note that this:
public static DoMath getInstance() {
if(_instance == null) {
_instance = new DoMath();
}
return _instance;
}
is not thread-safe. To ensure that your class really is a Singleton (relative to its ClassLoader) you must either synchronize that method or initialize the _instance member in its declaration. Either way, _instance must be private or final or both.
As for your actual requirements,
(1) it seems you want to either change an asynchronous call into a synchronous one, or to put a synchronous wrapper around it. You can do the latter via the existing listener interface, which would preserve the ability to perform asynchronous jobs. If you don't want that then instead of joining, skip launching a new thread at all: just run the computation in the current thread.
(2) How you might prevent multiple threads from running calculations at the same time depends in part on how you address issue (1). If you make everything synchronous then you can just make DoMath.performMathCalc() a synchronized method. If you retain the asynchronous computation option then you could look to package java.util.concurrent.locks for classes that can help you.
Do you really want to pause your thread until the other one as finished? You should never, ever block the main thread.
The join method allows one thread to wait for the completion of another. If t is a Thread object whose thread is currently executing,
t.join();
causes the current thread to pause execution until t's thread terminates. Overloads of join allow the programmer to specify a waiting period. However, as with sleep, join is dependent on the OS for timing, so you should not assume that join will wait exactly as long as you specify.
(from java docs)
Also, does performMatchCalc() needs to be public ?
Now, at first glance that code actually looks correct, but, you can still prevent someone from starting another calculation. Perhaps with something similar of this :
public class DoMath {
private Thread mathThread;
protected math calc() {
}
public static DoMath getInstance() {
if(_instance == null) {
_instance = new DoMath();
}
return _instance;
}
// perform a synchronous math calc, and return a boolean indicating success or failure.
public boolean performMathCalc() {
if(null != mathThread && mathThread.isAlive())
return false;
MathEngine.setApplicationMode(MathEngine.AUTO);
MathEngine.getInstance().StartMathCalc(MathEngine.DIVISION);
return true;
}
// perform an async math calc, and call back the listener when done
public void performMathCalc(final listener client) {
//re-start calculation? if so
if(null != mathThread && mathThread.isAlive()) {
matchThread.interrupt();
matchThread = null;
}
mathThread = new Thread(new Runnable() {
public void run() {
boolean result = performMathCalc();
client.mathFinished(result);
}
});
mathThread.setDaemon(true);
mathThread.start();
}
public static interface listener {
public void mathFinished(boolean success);
}
protected static DoMath _instance;
}
I need to have the calling thread wait until the DoMath class thread has completed.
You already have this. Note how there are two performMathCalc methods:
The first method takes no arguments and performs the calculation on the caller thread, then returns the result. This fulfills your first requirement.
The second method is an asynchronous wrapper for the first; it allows the caller to kick off a calculation, then go off an do something else with the understanding that, at some point in the future, someone will be notified that the operation has completed. This is useful functionality, so I would keep it.
I do see one issue with the asynchronous wrapper, however: the listener will not be notified in the event that the core performMathCalc() method throws an exception. Consider using a try/catch/finally block to ensure the listener always gets notified, even if an error occurs. You'll need to decide whether to add a second callback to your listener (e.g., mathFailed) or to simply call mathFinished(false) on errors.
I need to prevent other threads from calling it.
We can accomplish this easily enough, and since the asynchronous version simply delegates to the synchronous version, we only need to lock down the synchronous version. The simplest way would be to mark the method as synchronized, since your class only provides one logical function:
public synchronized boolean performMathCalc() {
MathEngine.setApplicationMode(MathEngine.AUTO);
MathEngine.getInstance().StartMathCalc(MathEngine.DIVISION);
return true;
}
Alternatively, if you end up extending your DoMath class to perform other kinds of operations that are not mutually exclusive, you can synchronize on operation-specific locks.
That leaves us with your singleton accessor:
public static DoMath getInstance() {
if (_instance == null) {
_instance = new DoMath();
}
return _instance;
}
This conditional initialization is not thread-safe. Your singleton is very simple and doesn't have any up-front initialization costs, so simply mark _instance as final static and initialize it in the declaration.
I was going through an "JAX London 2011" presentation on "Modern Java Concurrency". Between the time duration 43:20 - 43:40, a person from the audience says the shutdown variable in the code below should have been declared as volatile and the presenters agree with it (and say that it was pointed out earlier as well, but they just didnt get to modify the presentation). The code in question is:
public abstract class QueueReaderTask implements Runnable {
private boolean shutdown = false;
protected BlockingQueue<WorkUnit<String>> lbq;
public void run() {
while (!shutdown) {
try {
WorkUnit<String> wu = lbq.poll(10, TimeUnit.MILLISECONDS);
if (wu != null) { doAction(wu.getWork()); }
} catch (InterruptedException e) {
shutdown = true;
}
}
}
public abstract void doAction(String msg);
public void setQueue(BlockingQueue<WorkUnit<String>> q) { lbq = q; }
}
My Question:
I dont think that shutdown should be declared volatile.
My reasoning is that shutdown being a member of a Runnable, each task/thread will have a distinct private copy of that variable. So, why make it volatile?
But since this was discussed in JAX 2011, I am assuming there were lots of expert Java developers in that audience. I dont think all of them would have missed this !
So, what am I missing ?
P.S:-
I can understand that a variable should be declared volatile if it was (potentially) shared by multiple threads, as in the Double-Checked-Locking pattern :
class Foo {
private volatile Helper helper = null;
public Helper getHelper() {
if (helper == null) {
synchronized(this) {
if (helper == null)
helper = new Helper();
}
}
return helper;
}
}
each task/thread will have a distinct private copy of that variable. So, why make it 'volatile' ?
You are correct if the shutdown boolean is only modified from within the QueueReaderTask instance. In that case shutdown is only being modified by the one thread and doesn't need to be volatile.
Frankly, the code looks strange to me. Why catch InterruptedException, set the shutdown boolean, and then loop around and exit. Why now just do the following? Why have the shutdown flag at all?
while (true) {
try {
WorkUnit<String> wu = lbq.poll(10, TimeUnit.MILLISECONDS);
if (wu != null) { doAction(wu.getWork()); }
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
return;
}
}
Maybe there is extra code that was removed in the post? If not, I wonder if this was copy and pasted from a larger section of code where shutdown was set to true also in a method call.
P.S:- I can understand that a variable should be declared 'volatile' if it was (potentially) shared by multiple threads, as in the Double-Checked-Locking pattern :
Right. A typical pattern is that shutdown is modified from another thread which is telling the thread to stop processing. In that case it needs to be volatile.
I have this piece of code below as shown .
Our Application runs on 5 web servers controlled by a Load Balancer ,all connecting to one Memcache instance .
I guess that this piece of synchrnozation works only for one Instance .
Please let me know how can i synchrnoze this piece of code when 5 web servers are trying to access the Memcache
public class Memcache {
private MemcachedClient memclient = null;
private static Memcache instance = null;
public static Memcache getInstance() {
if (instance == null) {
try {
synchronized (Memcache.class) {
instance = new Memcache();
}
} catch (IOException e) {
throw new RuntimeException(e);
}
}
return instance;
}
private Memcache() throws IOException {
MemcachedClientBuilder builder = new XMemcachedClientBuilder();
memclient = builder.build();
}
}
Why not initialize it like this?
private static Memcache instance = new Memcache();
Bare in mind that what you tried to achieve at the synchronization here is problematic,
As two threads might pass the (if (instance == null) (a context switch might be after that line)
So you can consider the double check pattern,
BUt at some version of java there is a problem with it.
At the link I provided , there is info about problem, and
in this link, you can read about Singleton with the volatile keyword.
I still would go for the option I suggested above.
You can use the lazily initialized ClassHolder pattern to implement synchronized access to a class. Because the Memcache is initialized with a static initializer, it doesn't need more synchronization constructs. The first call to getInstance() by any thread causes MemcacheHolder to be loaded and initialized and the Memcache instance to make itself available to the calling code.
public class MemcacheFactory{
private static class MemcacheHolder {
public static Memcache instance = new Memcache();
}
public static Memcache getInstance() {
return MemcacheFactory.MemcacheHolder.instance;
}
}