precautions related to run() method of thread? [closed] - java

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.

Related

Is run Method is only way to achieve Multi Threading [closed]

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 3 years ago.
Improve this question
I want to run simultaneously two different methods in two different classes
Is run method is the only way?
If it is Why??
Your code snippet does not show how you actually start these threads, I am assuming something like new Thread2().start(). What this does is create a new thread and the new thread proceeds (in the background) to execute its run method (and then terminates when that method returns).
Every thread runs code that is contained with a run() method. That is just how threads work. There has to be some convention to let the JVM know where the code for the thread is.
From within that method, you can call any other method on any other object that you have access to.

JavaFX Task vs plain old Thread, what are the differences? [closed]

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.

One thread for each mob in a 2D game: Will it be system-resource consuming? [closed]

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 6 years ago.
Improve this question
I'm developing a java 2D game, with a Board class and Mob(s) class. The board class has a thread that calls 'repaint()' every a specified delay, while the mobs class constructs a new thread for each of the mob spawned, which means when it does something, it ticks its time on its own. Simply said, I seperate the thread to enable frame rate setting. So i just need to only set how long does the Board thread sleep, like faster sleep means more frame rate (I use threads for this because a site says threaded timing can be made real precise). But then it means in a crowded in-game situation there would be a lot of thread running from every active Mob there.
My question: if i have this lots of thread running at the same time, wouldn't it be consuming a lot of system resources? And if yes, what is the best way round so I don't need to use threads? (just to note 2D game "crowded" situation can be "really crowded").
I think your question could resume to one of these :
Why is creating a Thread said to be expensive?
How expensive is creating of a new thread in Java? When should we consider using of a thread pool?
Is it expensive to create the Thread object or to actually start the thread?
etc...
Plenty of resource to find info on the subject.
what is the best way round so I don't need to use threads
This question is not appropriate for SO (too broad)

terminate the threads in java [closed]

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
if(thread.isalive())
{ // Terminate it such that no CPu memory and resources should be used
}
I want to terminate the threads so that no computers resources and memory would be used.Please Guide me in this
In Java threads will terminate itself after the code in it finished. You don't need to do this manually. If you want to terminate a running thread just call interrupt and the thread will terminate.
You wouldn't find a live thread after you started it unless:
A) It is still running
B) It is taking a while for the teardown procedure
Therefore, don't. If a thread still runs, it runs for a good reason. If you need task cancellation, there are better ways, such as interruption, boolean check within the run() method.
The Thread.stop() method will terminate the thread but it is deprecated:
http://docs.oracle.com/javase/7/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html
To terminate a thread, it have to reach the return statement in his run method. You can handle the return by checking a variable and set it as you need.

Java Synchronization [closed]

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.

Categories