Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Aside from the properties to know the state of the task and the call backs (completed, failed, etc), is there any other differences of using JavaFX Task over a plain old Java Thread with a lambda?
I'm not asking what's good or bad, I'm not asking what you think I should do, I'm asking for the objective factual differences that would happen when using a Task instead of a plain lambda to run a background thread in a JavaFX application. Aside from the the differences that I already mentioned.
On the Oracel's tutorial for concurrency, in the section titled "Why Use the javafx.concurrent Package?" it says:
If you have special requirements or need extra power over the code, implementing a background worker by creating a Runnable object and a new thread is an appropriate way to go.
other than that, all the reasons for using a Task are equally applicable to a Runnable and I don't see what special requirements or extra power one gains, I also don't see what you lose, if anything, aside from state and callbacks, when choosing Runnable over Task. What I do see is that using Task is much more verbose:
new Thread(this::doSomething).start();
vs
new Thread(new Task<Void>() {
#Override
protected Void call() throws Exception {
doSomething();
return null;
}
}).start();
My concern would be the some unexpected side effect from choosing a shorter more concise version of the code that according to Oracle, should only be used in special cases.
doSomething is a variety of different activity on this example and I'm interested in facts that are agnostic to what they do. In my case, it's mostly network requests that then update the UI by using Platoform.runLater.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
Can you explain short guide about background thread in 2021? I mean what is last recommendation to use, what was deprecated.
When I tried to found the information about it, I have confused. One place told about Thread, another Executor, the next about AsyncTask and so on. Every contains note or comment about obsolescence and not recommended by Google. What is true?
It really depends on what you are trying to do. Generally, the guide to background processing which was already linked by Dmitry in your comments is a good place to start.
Regarding the things you mentioned:
A Thread is useful if you have long-running tasks which do not happen all the time. Then you can create a thread whenever needed and it will be destroyed as soon as it's done executing.
By Executor I guess you are referring to the use of an ExecutorService. This is a class to manage a pool of threads. That is, you can give a job to the ExecutorService and it will assign it to any of its threads for execution. This is more efficient than creating a thread yourself every time, because the threads are not immediately destroyed after their work is complete. However, they will also stay in the memory because of that. Thus, an ExecutorService is suitable if you have short background jobs which occur often.
As for the AsyncTask, this API is indeed deprecated by now.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have a server with multithreading.
Each connection has it's own thread. The thread sometimes needs to access some methods from an Object and the method could be only called once at a time. So what would be better for the performance: Just to create a new object for every thread when it need to use it. Or sharing one global object which has synchronized methods?
synchronizing would not lead you to better performance. It could potentially make the performance worse if done incorrectly.
You are not showing any code so there is no way for us to give you any advice on what to focus on optimizing.
As a general advice:
1) Avoid any state if possible. This way synchronized is not needed
2) Make state immutable if the object needs to have a state. This way you don't care about synchronizing and avoid tedious bugs
3) If object creation is cheap then just do that using (2) if possible
4) If object creation is heavy look into singleton pattern and try to use locks on the methods.
And about
Each connection have its own Thread
Make sure you use a thread pool
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Last week I went for an interview, and during the interview one of the interviewer asked this question with me,
Q. What precaution do you take will writing a run() method?
and my answer was deadlock, livelock, synchronization, starvation and few of the overhead, but
he was not satisfied with my answer. He told no there are some other thing when we write run() method you should take care of...
I wrote run() like this during interview..
class DrawCircle implements Runnable {
public void run(){
//some code here
}
}
can any body tell me what is proper way of writing run() in any Runnable thread?
Nothing obvious but these:
Make sure your run method actually returns after finishing the task or it timeout after some defined threshold. If run() is stuck somewhere then thread will never finish. And if for some reason all your threads are getting stuck, and you have large number of threads, then it may crash your system.
If you are extending the Thread class, then make sure that you override the correct method. To be safe, adding #override on top of the method is good.
If you are implementing an anonymous thread then make sure you assign it to a Thread instance. If your run method goes into a bad state/infinte loop. You may be able to interrupt the thread using the instance.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I find the method wait() in the class Object.
It is final which means that this method cannot be overriden.
Any ideas why it's final?
#Flavio - it's actually a very good question.
The reason you can't override it, of course, is that the designers made it "final".
A couple of potential reasons for this decision:
You don't want people to mess with the semantics of a fundamental operation on a fundamental class (class "Object").
Since it's "final", compilers can optimize performance (save a few cycles) by in-lining "wait()"
"final" increases the security of the Java object model by preventing malicious code from exploiting "wait()".
It is not designed to be overriden, that's why. The method wait() calls wait(long timeout) which is final and native. So the latter is not supposed to be overriden and the no-paremeter version is just final so it is not supposed to be overriden too.
If you override a very basic functionality available for all Objects then it is highly likely that you will blow up your software or ruin your colleague's day.
If you check the documentation of wait():
Causes the current thread to wait until another thread invokes the
notify() method or the notifyAll() method for this object.
it turns out that it works in tandem with notify() and notifyAll() so you can't change it without altering their functionality. Not to mention the dozens of concurrent libraries using those methods.
It has a fairly concrete implementation that does not need to be modified. The logic behind wait() should be synonymous across all objects
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What is this:
synchronized (this) {
// ...some code...
}
good for?
(Could you write an example?)
It prevents concurrent access to a resource. Sun's got a pretty good description with examples.
It prevents multiple threads from running the code contained within the braces. Whilst one thread is running that code, the remainder are blocked. When the first thread completes, one of the blocked threads will then run the synchronised code, and so on.
Why do you want to do this ? The code within the block may modify objects such that they're in an inconsistent state until the blocks exits. So a second thread coming in would find inconsistent objects. From that point on chaos ensues.
An example would be removing an object from one pool and inserting it in another. A second thread might run whilst the first thread is moving the object, and subsequently find the object referenced in both collections, or neither.
You can also use this mechanism to restrict multiple threads from accessing a resource designed to be used by one resource (e.g. a trivial database, for example).
Note that the following two are equivalent:
synchronized void someMethod() {
// ...
}
and
void someMethod() {
synchronized (this) {
// ...
}
}
From the now-defunct Java Quick Reference formerly at http://www.janeg.ca/scjp/threads/synchronized.html:
Synchronizing threads has the effect
of serializing access to blocks of
code running on the thread.
Serializing in this context means
giving one thread at a time the right
to execute specific block of code.