1) If a class (say TestClass) has two methods (method1, method2). Two threads (t1, t2) are running parallely where t1 is calling method1 of an object object1 (of type TestClass), and t2 is calling method2 of the same object (object1).
What happens if, only method1 is synchronized, and method2 is not?
If both methods are synchronized, then will both run parelley? (its not running, but why?, we can achieve this with two dummy objects and block level synchronization)
In the below, method1 and method2 of a same object can be executed parallely with two threads?
void method1() {
synchronized(object1) {
....
}
}
void method2() {
synchronized(object1) {
....
}
}
What is the usage of synchronized block with .class synchronized(TestClass.class) { }
If only method1 is synchronized, then method2 and method1 can be executed in parallel.
If both methods are marked synchronized they cannot run in parallel.
I think what's confusing you here is the synchronized keyword. A synchronized method will be synchronized for that instance of class. Like so:
synchronized void Method1(){}
synchronized void Method2(){}
These methods can only be entered if the instance they're defined in is not being used to execute a synchronized block of code elsewhere. Compare that to this:
void Method1(){
//can run in parallel
synchronized(this){
//cannot run in parallel.
}
//can run in parallel.
}
void Method2(){
synchronized(this){
//cannot run in parallel.
}
}
This is not quite the same. Both methods can be entered, but code within the synchronized block cannot run in parallel.
Lastly, if you synchronize on TestClass.class it will prevent code anywhere synchronizing on the same object from executing. This is true when synchronizing on any static object.
they can run concurrently
no, only one thread can have the lock of the object at a time. So, while one thread executes method1 or method2, no other trhread can execute any of these two methods on the same object.
no, since they both need to have the lock of the same object to execute
To prevent other threadd to execute static synchronized methods of the TestClass concurrently, or any block synchronizing on the same Class object.
As long the methods do not change state of the/any object in common scope, there is no need to sync. The interessting part is in .....
Related
What does this java code mean? Will it gain lock on all objects of MyClass?
synchronized(MyClass.class) {
//is all objects of MyClass are thread-safe now ??
}
And how the above code differs from this one:
synchronized(this) {
//is all objects of MyClass are thread-safe now ??
}
The snippet synchronized(X.class) uses the class instance as a monitor. As there is only one class instance (the object representing the class metadata at runtime) one thread can be in this block.
With synchronized(this) the block is guarded by the instance. For every instance only one thread may enter the block.
synchronized(X.class) is used to make sure that there is exactly one Thread in the block. synchronized(this) ensures that there is exactly one thread per instance. If this makes the actual code in the block thread-safe depends on the implementation. If mutate only state of the instance synchronized(this) is enough.
To add to the other answers:
static void myMethod() {
synchronized(MyClass.class) {
//code
}
}
is equivalent to
static synchronized void myMethod() {
//code
}
and
void myMethod() {
synchronized(this) {
//code
}
}
is equivalent to
synchronized void myMethod() {
//code
}
No, the first will get a lock on the class definition of MyClass, not all instances of it. However, if used in an instance, this will effectively block all other instances, since they share a single class definition.
The second will get a lock on the current instance only.
As to whether this makes your objects thread safe, that is a far more complex question - we'd need to see your code!
Yes it will (on any synchronized block/function).
I was wondering about this question for couple days for myself (actually in kotlin). I finally found good explanation and want to share it:
Class level lock prevents multiple threads to enter in synchronized block in any of all available instances of the class on runtime. This means if in runtime there are 100 instances of DemoClass, then only one thread will be able to execute demoMethod() in any one of instance at a time, and all other instances will be locked for other threads.
Class level locking should always be done to make static data thread safe. As we know that static keyword associate data of methods to class level, so use locking at static fields or methods to make it on class level.
Plus to notice why .class. It is just because .class is equivalent to any static variable of class similar to:
private final static Object lock = new Object();
where lock variable name is class and type is Class<T>
Read more:
https://howtodoinjava.com/java/multi-threading/object-vs-class-level-locking/
Why sleep() and yield() methods are defined as static methods in java.lang.Thread class?
The code would only execute when someXThread was executing, in which case telling someYThread to yield would be pointless. So since the only thread worth calling yield on is the current thread, they make the method static so you won't waste time trying to call yield on some other thread.
This is because whenever you are calling these methods, those are applied on the same thread that is running.
You can't tell another thread to perform some operation like, sleep() or wait. All the operation are performed on the thread which is being executed currently.
If you call the yield or sleep method, it applies to whichever thread is currently executing, rather than any specific thread - you don't have to specify which thread is currently running to free up the processor.
similar thread in this forum
The same reason is why stop() and suspend() methods are deprecated. Intrusion in thread's state from outside is dangerous and can cause unpredictable result. And if sleep is not static, for example, how do you think interruption from it will happen?
They are static so that overriding concept can be avoided i.e.
When they are called with parent class reference to hold child class object like situation it implements Method Hiding concept and not overriding due to Static method nature, i.e parent class(here thread class) method will run which have the complete functionality of sleep and yield.
http://i.stack.imgur.com/goygW.jpg
Both sleep and yield methods are native. To understand better from above answers I made two classes ClassA and ClassB with same static method. I invoked method of other class to check its behavior. So we can call other class' static method.
So may be there is other reason behind making sleep method static.
public class ClassA {
public static void method(){
System.out.println("Inside ClassA method");
}
public static void main(String[] args) {
method();
ClassB classb = new ClassB();
classb.method();
}
}
public class ClassB {
public static void method(){
System.out.println("Inside ClassB method");
}
}
I know I am late to this party, (blame my parent :-))
I would like to answer this using proof by contradiction.
Let's say sleep method is not static so you can call sleep on any other thread object.
Let's say there are two threads, thread A and thread B. Now consider two possible scenarios in the context of sleep method, the same applies to yield as well.
System having single processor has only one thread active at a time, so if thread A calls sleep on thread B object i.e. B.sleep(), B is not in execution, as currently executing thread is thread A, so calling sleep on non-executing method is pointless.
A responsible programmer would never define sleep inside a synchronized block, or when a thread is holding a lock. But let's say thread A calls sleep method on thread B just when thread B is holding a lock(or inside a synchronized block), thread B would go to sleep holding lock which is totally undesirable.
These are just a few situations which forced jvm to not allowed thread to call sleep on another thread obect.
I have a class as
public class ThreadExample extends Thread{
static int count = 0;
public static synchronized int increment(){
return count++;
}
public synchronized int decrement(){
return count--;
}
}
Here I have one static method and one non-static method.
First thread1 have called method increment() which is synchronized.It acquires lock on class level.
Here my question is if another thread2 is calling decrement() method will that thread2 will acquire lock on decrement() and how it works?
The synchronized keyword has two possible uses. It can be used as a modifier for methods, and it can be used as a statement. Besides, the synchronized modifier can be combined with static, and in that case the target object will be the enclosing class instead of the enclosing instance.
Scope | modifiers | corresponding statement
---------+---------------------+------------------------
static | synchronized static | synchronized (X.class)
instance | synchronized | synchronized (this)
If a method is static synchronized, the lock is acquired on the class object of the enclosing class, in your case on ThreadExample.class.
Although they're compiled into different byte code, the following two methods are equivalent:
public class Foo {
// static method with synchronized modifer
public static synchronized void foo1() {
// ...
}
// equivalent synchronized statement
public static void foo2() {
synchronized (Foo.class) {
// ...
}
}
}
If a method is synchronized (without static), the lock is acquired on the instance itself. Although they're compiled into different byte code, the following two methods are equivalent:
public class Foo {
// instance method with synchronized modifier
public synchronized void foo3() {
// ...
}
// equivalent synchronized statement
public void foo4() {
synchronized (this) {
// ...
}
}
}
So, increment() and decrement() are synchronized differently, and there can be a race condition.
Therefore, the variable count is not sufficiently protected from concurrent update.
++ and -- cannot be atomic themselves, as incrementing or decrementing a value requires a read-update-write cycle. Technically it could be atomic because some CPUs provide atomicity for that by providing corresponding instructions which will keep the bus / address obtained for themselves until the operation is performed. But the JVM does not rely on such things.
If you need a atomic int, you might want to look at java.util.concurrent.atomic.AtomicInteger.
How to do synchronized in C
synchronized is implemented with the VM environment methods MonitorEnter() and MonitorExit().
Pitfalls
When you use the synchronized modifier, you synchronize on something which is more or less public, i.e. visible to other objects and classes as well. The Monitor feature of java.lang.Object which provides the underlying facility for synchronized is public, as well as the native functions MonitorEnter() / MonitorExit() and the wait pool methods wait(), notify() and notifyAll(). This can lead to unexpected bugs and deadlocks if "somebody else" is also using "your object / your class" for synchronization.
Therefore it has become a pattern to actually not use the synchronized modifier but instead use synchronized statements on a private lock object, like this:
public class Foo {
private final Object lock = new Object();
public void foo() {
synchronized (lock) {
// ...
}
}
}
Now Foo can no longer be disturbed or blocked by somebody else synchronizing on it. You might think there might be a reasonable use case for that, but I think if you have a use case for locking across object / class boundaries, there's probably a big flaw in the design - things are not self-contained enough.
If you need a class lock instead of an instance lock, just make the variable static.
Note that when doing serialization, you will have to take care of the lock object. The simplest way is to actually not use Object, but this:
public class Lock implements Serializable {}
If you want to save serialization storage, you can declare the lock transient and recreate the lock during deserialization, but be careful about transient final, you need reflection or readResolve() for them, but that's a different story.
Calling synchronized static methods tries to acquire the lock of the class object. (ThreadExample in your case), while calling synchronized non-static methods tries to acquire the lock of the particular instance object. So essentially you are acquiring 2 different locks and thus your code is not thread-safe. The data count may be corrupted due to race condition
Oracle tutorial:
You might wonder what happens when a static synchronized method is
invoked, since a static method is associated with a class, not an
object. In this case, the thread acquires the intrinsic lock for the
Class object associated with the class. Thus access to class's static
fields is controlled by a lock that's distinct from the lock for any
instance of the class.
Static and instace level locks are two different locks and they are independant of each other.
Regarding scenario in question "First thread1 have called method increment() which is synchronized.It acquires lock on class level. Here my question is if another thread2 is calling decrement() method will that thread2 will acquire lock on decrement() and how it works"
even if thread1 is holding (class level)lock on increment method and thread2 calls decrement method it should aquire a (instance level)lock .
problem is not with aquiring the lock problem might start when they are trying to updated the shared variable.If two threads are trying to access count variable (one through static locking and other through instance level locking ) at a same time then there might be a RACE condition between two threads.
As suggested by Christian you can overcome this by using java.util.concurrent.atomic.AtomicInteger instead of int
For more details please visit URL
A static synchronized method and a non-static synchronized method will not block each other. The reason is static method locks on a Class instance while the non-static method locks on the this instance— both actions do not interfere with each other at all.
In your code one method is static synchronized and another method is just synchronized. Your code is not thread safe, even if two threads are executing two methods on same object, one thread (executing non-static method) acquires object level lock and proceed. Another thread executing static method acquires class level lock (i.e. ThreadExample.class ) and proceeds. Remember that static methods are always class level.
To make your code thread safe you need to have below changes in your example.
public static synchronized int decrement(){
return count--;
}
I was reading about JAVA synchronization.
I have 2 methods in my class.
public synchronized void eat()
{
System.out.println("eat");
eatDinner();
}
public synchronized void eatDinner()
{
System.out.println("eat");
}
Both of my methods are synchronized.
Now Is it possible for 2 threads one is calling eat() and another eatDinner() to run simultaneously?
And If thread2 has not still executing eatDinner() . Can thread1 can call eatDinner() from eat()?
No, it is not possible for two threads to run the methods eat and eatDinner simultaneously. (Caveat: as long as these methods are invoked on the same instance of the class)
The synchronized keywords, when applied to a non-static method, synchronizes on the object itself.
Your code can be rewritten, without changing the meaning, as:
public void eat() {
synchronized (this) {
System.out.println("eat");
eatDinner();
}
}
public void eatDinner() {
synchronized (this) {
System.out.println("eat");
}
}
This probably makes it easier to see that they are both synchronizing on the same monitor.
Each java object has a monitor.
As long as 'thread1' is holding the monitor of your object, it can enter other synchronized blocks on the same monitor. 'thread1' has to exit all synchronized blocks (exist the blocks as many times as it has entered them) before another thread can take ownership of the monitor.
So thread1 can call eatDinner if it is already in the eat method - no problem. But if thread2 is currently in the eat method, then thread1 will block when it calls eatDinner until thread2 has finished both eatDinner and eat.
Addition:
In response to your comment
#Raj: If two threads are created by same class instances, then?
It is not important how the threads were created - it doesn't matter if that happened from within the same class or from completely different locations in your code. Two different threads are always independent.
It only matters on which object's monitor you synchronize: each object instance has one 'monitor'. You can't see this monitor - it doesn't have a name, but it's there and it is used by the synchronized keywords and by the wait, notify and notifyAll methods defined in java.lang.Object.
"Now Is it possible for 2 threads one is calling eat() and another eatDinner() to run simultaneously? "
on the same instance, no. they will block and only one will execute at once. different class instances, yes, they will not block eath other.
"Can thread1 can call eatDinner() from eat()"
yes. the lock is reentrant.
If 2 threads call methods on different class instances they can run methods simultaneously
I have a class
class Foo{
static synchronized get(){}
synchronized() getMore(){}
}
I have 2 objects Foo.get() and f.getMore() running in 2 different threads t1 and t2. i had a dobuts whether when thread t1 had got a lock on the class can thread t2 access the method getMore or would t2 be prevented from getting the access and the lock to the method since the class object is locked by t1.
The static method will synchronise on the Class object as opposed to the instance object. You have 2 locks operating on 2 different objects. In your scenario above there will be no blocking behaviour.
Static Synchronized ---> Class Level Locking (Class level scope)
it is similar to
synchronized(SomeClass.class){
//some code
}
Simple Synchronized ---> Instance level locking
Example:
class Foo{
public static synchronized void bar(){
//Only one thread would be able to call this at a time
}
public synchronized void bazz(){
//One thread at a time ----- If same instance of Foo
//Multiple threads at a time ---- If different instances of Foo class
}
}
synchonized locks an object and a static synchronized locks the object which represents the class.
t1 and t2 can call these methods concurrently except they cannot both be in the static synchronized method unless all but one thread is wait()ing.
Note: t1 and t2 can call getMore() at the same time for different objects.
The synchonized static method will aquire the lock Of java.lang.Class object which is assosiated on behalf of Foo class.
The synchonized instance method will aquire the lock of Actual object.