This question already has answers here:
Is using Object.wait and Object.notify directly a code smell?
(2 answers)
Closed 7 years ago.
My question is about using wait() and notify() explicitly. Whould we try to avoid it every time we need something like producer-consumer and consider to use BlockingDeque instead.
I tried to think about it and didn't find more or less reasonble explanation. Moreover I tried to invent example where we would have to use wait() and notify() explicitly and failed.
There are better higher level constructs in java.util.concurrent, so using wait/notify nowadays is highly dubious.
Related
This question already has answers here:
Java ArrayList.add() method thread safe for purely parallel adding? [duplicate]
(6 answers)
Closed 3 years ago.
I want to add information to a List and that information is gathered from multiple threads. The threads do not need to pull data from the list. Is it safe to have a regular ArrayList or LinkedList? Or what other ways can I do this?
Regular collections are not thread safe, but there are ways to circunvent that:
You can use CopyOnWriteArrayLists, but they are very expensive to write, you can also create a Syncronized Collection, which are not so expensive to write, and you can also work with Queues, it will depend on what you want to achieve.
This question already has answers here:
In Java, what is the difference between this.method() and method()?
(9 answers)
Closed 4 years ago.
I have been studying Akka Actors. I know the meaning of stop(ActorRef) which kills the running actor. But what is the difference between getSelf() and this.getSelf() while killing an actor? Thank You in advance!.
There's no difference between them, it's just that some people believe it enhances readability.
Readability is an important thing in programming but in this specific case, I personally believe they are just as readable with or without the this prefix.
This question already has answers here:
"implements Runnable" vs "extends Thread" in Java
(42 answers)
Closed 8 years ago.
I have studied that we can create threads in two ways in java :
By extending Thread Class
By implementing Runnable interface under which we have to implement run()
Now my question is what is the difference b/w the two?
Is any 1 faster or efficient than other? something related to binding here or linking?
A Thread is a resource for performing work.
A Runnable is a unit of work.
Are you creating a new type of resource, or defining work? It's almost always the later.
In the simplest case there isn't really any functional performance difference. However, creating Runnables allows you to utilize Thread pools without changing your code much, which is a huge boost over using new Thread() in many cases.
This question already has answers here:
What is a deadlock?
(19 answers)
Closed 9 years ago.
What is deadlock in programming Object Oriented ?
I had knew deadlock in transaction of Database Systems. But in programming I'm not clear.
I want to know when deadlock occur and how to resolve it.
Thanks!
A deadlock is when you have two or more processes that are each waiting for the other to finish. When this happens, neither one can continue and the program essentially stalls.
There is a basic example here
http://docs.oracle.com/javase/tutorial/essential/concurrency/deadlock.html
well documented.
but, a deadlock occurs when you wait for a object to be freed but that condition is never achieved.
This question already has answers here:
Write to FileOutputStream from multiple threads in Java
(4 answers)
Closed 5 years ago.
Is there any thread-safe substitute for java.io.OutputStreamWriter in the JDK or some third party library?
None that I know of.
But you can use other means to effectively achieve thread-safety, like protecting the OutputStreamWriter with some monitor, Lock, or Semaphore. Also, you can use a single-threaded ExecutorService as a unique bottleneck through which other threads submit writing "jobs".
I answered this question: Write to FileOutputStream from multiple threads in Java
, which is exactly the same.
The short answer is no, but there are ways around it.