You might think that this question is duplicate of this one but no answers of that question helps me for understanding synchronized method in android. I searched a lot on google for understanding synchronized methods and i found some answer but they didn't help me to perfectly understand Synchronized methods because no answer has any perfect practical example.
I have tried to understand synchronized method by implement 2 synchronized methods in my code and executing them concurrently but i am failed in properly implementing them. So, please provide explanation of synchronized method with simple example so, others like me also can understand it simply and in a faster way.
UPDATE
I am not sure i am going in right direction or not but i have tried following code which have 2 synchronized methods.
synchronized void add() {
counter++;
Log.e("JK", String.valueOf(counter));
}
synchronized void minus() {
counter--;
Log.e("JK", String.valueOf(counter));
}
and i have called this methods in two different threads using below code.
new Handler().postDelayed(new Runnable() {
#Override
public void run() {
synchronized (counter++) {
add();
}
}
},500);
new Handler().postDelayed(new Runnable() {
#Override
public void run() {
minus();
}
},1000);
Synchronized method is a method which can be used by only one thread at a time.
Other threads will be waiting until the method will be released.
You should have only serious reasons to declare method as synchronized because such method decreases the productivity. The classic case of synchronized method usage is when several threads are using same resources i.e. change state of some object and it is needed to make sure only one thread performs it at a time, otherwise it will cause inconsistency. Also make sure to make synchronized method as small as possible, ideally reduce it to contain only operations which can manipulate common resources.
For example the class Reporter has common resource fileWriter. It writes to file some messages with information about authors.
class Reporter{
private FileWriter fileWriter;
public synchronized void addRecord(String author, String message) throws IOException {
fileWriter.write("\n<<<<<<<<<<>>>>>>>>>>\n");
fileWriter.write("Message written by:" + author + "\n");
fileWriter.write("Message content:" + message);
}
public Reporter(FileWriter fileWriter) {
this.fileWriter = fileWriter;
}
}
Suppose you are running this code from 2 different threads:
Reporter reporter = new Reporter("path/report");
...
Thread thread = new Thread(){
public void run(){
reporter.addRecord("John", "Hi");
}
}
thread.start();
Thread thread2 = new Thread(){
public void run(){
reporter.addRecord("Bill", "Hello");
}
}
thread2.start();
The result for synchronized method will be like this :
<<<<<<<<<<>>>>>>>>>>
Message written by:John
Message content:Hi
<<<<<<<<<<>>>>>>>>>>
Message written by:Bill
Message content:Hello
If method is not synchronized several threads may write to file simultanously, which can cause an unpredictable sequence in file, like this:
<<<<<<<<<<>>>>>>>>>>
<<<<<<<<<<>>>>>>>>>>
Message written by:John
Message written by:Bill
Message content:Hello
Message content:Hi
Synchronized method is a method which can be used by only one thread at a time. Other threads will be waiting until the method will be released. You should have only valid reasons to declare method as synchronized because such method decreases the productivity and performance.
Related
I stumbled across this method in a project i am working on, and immediately thought that something is wrong. I had the feeling this can't be any proper idom for anything.
But i don't get the intentions and implications of this. Can this be refactored? Does the second synchronized make any sense - and isn't the third synchronized redundant/unnecessary?
I am just starting to get into advanced concurrent/threadsafe programming in java - a detailed explanation why this makes sense or no sense and why is much appreciated!
#Override
public synchronized void run() {
synchronized (this.market) {
synchronized (this.market.getWallet()) {
this.handler.handleEvent(new WalletLecherEvent(this, market,
market.leechWallet()));
}
}
}
thanks in advance
edit, in order to supply more context:
public class WalletLeecherWorker extends Worker {
private IAbstractMarketAPI market = null;
private Thread thread = null;
public WalletLeecherWorker(IEventHandler handler, IAbstractMarketAPI market) {
super(handler);
this.market = market;
}
public void startThread() {
if (thread != null)
return;
thread = new Thread(this);
thread.start();
}
public MARKETs getMarket() {
return this.market.getName();
}
#Override
public synchronized void run() {
synchronized (this.market) {
synchronized (this.market.getWallet()) {
this.handler.handleEvent(new WalletLecherEvent(this, market,
market.leechWallet()));
}
}
}
}
..and the method market.getWallet():
#Override
public Wallet getWallet() {
return this.wallet;
}
I think that the intention is to block all threads from getting old Wallets, thus wrongfully synchronized/ deprecated data - as long as this thread runs();
The code obtains the locks on the following objects:
this - Prevents multiple threads from calling run() on the same WalletLeecherWorker instance
this.market - Prevents the run() from proceeding if another thread has obtained a lock on it, which is a reasonable assumption considering that the market instance is probably shared
this.market.wallet - Same as previous
None of these are obviously unnecessary, except for the run() method being synchronized. It offers no protection beyond what the following synchronized block does. The code itself could be because of very fine grained locking being used, with this particular code needing to lock everything, whereas other code may lock only the wallet or the market and the wallet.
However this code can be error (and even deadlock) prone. If you lock the objects in the wrong order, you can get a deadlock. It's also not very readable as you see. It's also dubious to have a Thread as an instance variable of the class with a startThread() method. The code may not be broken, but it's certainly not very pretty.
I'm doing a short course about Threads in Java, in one of my homeworks they asked me: ¿Why you don't should be synchronize the run method? show an example.
I searched about it, and that i think is use synchronized for a run method is not useful, at least commonly. Because the people don't call the run method manually, so the synchronized effect isn't visible creating multiple instances of a object with synchronized run.
So, i would like know if exist another reason or if i'm wrong.
Syncrhonizing the run() method of a Runnable is completely pointless unless you want to share the Runnable among multiple threads and you want to serialize the execution of those threads. Which is basically a contradiction in terms.
If the run method of a Runnable were synchronized, then either
a) you have many runnables (in which case, no need to synchronise, as each one is called on a different object), or else
b) you have one runnable being called in many threads - but then they clearly won't run in parallel -- thus defeating the purpose of having multiple threads!
You may synchronize on run method, nothing wrong with it. I think the reasons behind this advice should be explained to you by the instructor of course.
We need synchronization when there are shared resources (between threads).
Synchronizing on a method is same as synchronizing on this which will block other method calls.
As a counter example, a poor man's Future implementation;
public class SynchronizedRun {
static abstract class Future<T> implements Runnable{
private T value;
public synchronized T getValue(){
return value;
}
protected void setValue(T val){
value = val;
}
}
public static void main(String[] args) {
Future<Integer> longRunningJob = new Future<Integer> (){
#Override
synchronized public void run() {
try {
Thread.sleep(5000);
setValue(42);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
};
new Thread(longRunningJob).start();
System.out.println("getting results");
System.out.println("result = " + longRunningJob.getValue());
}
}
This code is from Effective Java (Item 66): (without sync or volatile this never ends)
public class ThreadPractice {
static boolean canrunstatic;
public static void main(String[] args) throws InterruptedException {
Thread backgroundThread = new Thread(new Runnable() {
public void run() {
int i = 0;
while (!canrunstatic){i++;}
System.out.println("finished");
}
});
backgroundThread.start();
TimeUnit.SECONDS.sleep(1);
canrunstatic = true;
}
As Bloch mentioned in that chapter it will never write "finished" to the console. I've been playing around with this class, and add that line to the runnable run method:
System.out.println("im still running");
With this the while loop doesn't only increment i but prints out this string in every loop. But what drives me crazy, that this way the thread stops after 1 sec, when main thread comes back from sleep.
modified: (stops without volatile/sync)
public class ThreadPractice {
static boolean canrunstatic;
public static void main(String[] args) throws InterruptedException {
Thread backgroundThread = new Thread(new Runnable() {
public void run() {
int i = 0;
while (!canrunstatic){i++;System.out.println("im still running");}
System.out.println("finished");
}
});
backgroundThread.start();
TimeUnit.SECONDS.sleep(1);
canrunstatic = true;
}
So what is the logic behind this?
Precisely, it is just not guaranteed that the thread will ever stop, but it is not forbidden that it does stop. The logic behind this is provided by the Java Memory Model, which is a rather complicated topic, but needed in order to understand Multithreading in Java.
The concept is that a write to a non-volatile field of one thread is only required to be seen by another thread if these two actions synchronize with each other. A compiler is allow to reorder some actions if the behavior exhibited by the thread it is executed in does not change. But another thread might see this. So you need proper synchronization in order to tell the compiler that reordering is not allowed in some parts.
Read the full paper about this here: JSR-133
Writing data to the console is often implemented a thread safe operation.
In that case your act of writing data to the console can also trigger updating of the canrunstatic variable as seen by your backgroundThread.
Note that this is not promised by the Java Memory Model, nor by the implementation of java System.out
I was going through some simple examples on threading/synchronizing from a book that claims the use of synchronized will allow access to the method by one thread being called on the same instance. It does serialize as promised but it seems that about 9/10 times the third Caller created in the Synch main method below comes before the second. This code is the example code showing the issues without a synchronized method.
class CallMe {
void call(String msg) {
System.out.print("[" + msg);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
System.out.println("CallMe Interrupted");
}
System.out.println("]");
}
}
class Caller implements Runnable {
String msg;
CallMe target;
Thread t;
public Caller (CallMe target, String msg) {
this.target = target;
this.msg = msg;
t = new Thread(this);
t.start();
}
#Override
public void run() {
target.call(msg);
}
}
class Synch {
public static void main(String args[]) {
CallMe target = new CallMe();
Caller c1 = new Caller(target, "Hello");
Caller c2 = new Caller(target, "Synchronized");
Caller c3 = new Caller(target, "World");
try {
c1.t.join();
c2.t.join();
c3.t.join();
} catch (InterruptedException e) {
System.out.println("Synch Interrupted");
}
}
}
The book shows two ways to deal with the issue, they are -
synchronized void call(String msg) {...} and
public void run() { synchronized (target) {...} }
It's clear that both options work because, as opposed to the original code, the bracketed words are consistent like...
[Hello]
[World] (about 90% of the time the calls are backwards)
[Synchronized](1/many have Synchronized as the first msg)
...there's no rhyme or reason to the original code. So I know it's "working" and can be seen directly by placing breakpoints on each of the Caller instantiations. It works every time, obviously to me, when I do.
Why is the third Caller consistently calling call before the second?
Threads by definition run in parallel, and none is given precedence over any other.
Once the threads are all launched it is essentially random which will run first, in general the first one launched will have a slight "head start" but that head start is tiny compared to the overhead of launching threads etc.
A quirk of your particular environment just happens to be favoring one thread, the results may well vary on different systems and certainly shouldn't be relied on.
Incidentally this is bad practice for a number of reasons:
public Caller (CallMe target, String msg) {
this.target = target;
this.msg = msg;
t = new Thread(this);
t.start();
}
(You probably got a compiler warning in fact).
Much better is to provide a start method
public Caller start() {
t.start();
return this;
}
and then do
new Caller(target, msg).start();
This absolutely ensures that the Caller object is fully initialized and ready to go before the Thread starts processing it.
Why is the third call consistently calling call before the second?
It's not doing so consistently - it's doing so about 90% of the time.
Basically, synchronization isn't guaranteed to be first-in, first-out... and there's no guarantee that the calls will even be made in the order you're expecting. Three new threads are being started in quick succession - there is no guarantee about which thread will actually start executing its code first.
Fundamentally if you want to impose ordering on parallel code, you need to do so explicitly. Synchronization doesn't provide ordering - it only provides exclusivity.
It does serialize as promised but it seems that about 9/10 times the third Caller created in the Synch main method below comes before the second.
Be careful to understand the meaning of "serialize" in your sentence: it means that all the code sections protected by the same lock will never run in parallel; in other words, their execution will be serial.
What it doesn't mean is "execution of these code sections will occur in a strict, specified order". It will not.
In java, I have 2 threads in my client, one is controlling the network flow, the other one is processing the messages, draws game etc. What I am trying to do is when a packet comes, the network thread will call messageReceived method of the game thread, containing the message as parameter. Will it block networking thread if i make the function messageReceived as synchronized and there are 2 packets sequentally come before messageReceived function ends, or it doesn't block and my packet is lost because network thread couldn't call messageReceived function which is already being used by game thread ?
When you use the synchronized keyword to sync a code section, then when another thread comes in that wants access to that section it will block until it can get access.
Correct, you're blocking on the IO thread. You want to only do light work on messageReceived() because of that ... perhaps only queue the message in some sort of FIFO for the processing thread to work on later. Your sync blocks should have as small a footprint as possible.
If a thread calls a synchronized method in a class, all the other threads will be blocked to call any synchronized method in that class because the object lock is not available. If your messageReceived is not working on any shared resource then keep it non-synchronized. In case it is using some shared resource then try to minimized the synchronized code by wrapping that code in synchronized block.
It sounds like you are attempting to solve a problem that could be easily avoided if you used a more mainstream design pattern such as the Observer Pattern. http://en.wikipedia.org/wiki/Observer_pattern
Its easy to conceptualize but im more of a visual person. Heres a bit of code that helped me long ago understand what excatly syncorized did and how it worked. If you watch the output you will see when you add the synchronized attribute to the print function that you never see As and Bs mixed. but when you remove it you will see a much different output. It should be straight forward once you see it.
public class Main {
public static void main(String[] args) {
(new ThreadA()).start();
(new ThreadB()).start();
}
// try it with removing the synchronized: public static void print(String str) {
public static synchronized void print(String str) {
for(int i = 0; i<100; i++)
System.out.print(str);
System.out.println();
}
public static class ThreadA extends Thread {
public void run() {
while(true) {
print("A");
}
}
}
public static class ThreadB extends Thread {
public void run() {
while(true) {
print("B");
}
}
}
}
Yes, synchronized blocks a thread if the implicit lock has already locked by another thread. But there is a non-blocking alternative - java.util.concurrent.locks.Lock that is more flexible
Lock.tryLock()
acquires the lock only if it is free at the time of invocation
and
Lock.tryLock(long time, TimeUnit unit)
acquires the lock if it is free within the given waiting time and the current thread has not been interrupted.