Reputation: 460
According to the title,look at this code:
Thread outer = new Thread(new Runnable() {
@Override
public void run() {
Thread inner1 = new Thread(new Runnable() {
@Override
public void run() {
//some statements and other inner threads
}
});
Thread inner2 = new Thread(new Runnable() {
@Override
public void run() {
//some statements and other inner threads
}
});
//some statements and other inner threads
}
});
So, is it a good practice to use multithreading like this?
Regards
Upvotes: 1
Views: 1949
Reputation: 3151
This Java Code Geeks article on concurrency has a few recommendations for you. I would suggest you read it in its entirety but here are two important snippets:
Typically, it is not recommended to directly create and manage threads using the instances of Thread class...
and this:
Creating new threads in Java is easy, but managing them is really tough. Java standard library provides extremely useful abstractions in the form of executors and thread pools targeted to simplify threads management.
Essentially, in its simplest implementation, thread pool creates and maintains a list of threads, ready to be used right away. Applications, instead of spawning new thread every time, just borrows the one (or as many as needed) from the pool. Once borrowed thread finishes its job, it is returned back to the pool, and becomes available to pick up next task.
Though it is possible to use thread pools directly, Java standard library provides an executors façade which has a set of factory method to create commonly used thread pool configurations.
Threads have a lot of states to manage, which is also identified in the article:
Here are additional considerations from the below answers to this question:
Yes, you can launch as many threads as you want, but that's probably not the best way to go. It's much better to use the non-blocking API's so that you can start execution of some external call and the calling thread can immediately start doing something else without waiting on the socket/database call to come back. Then, when the socket/database call comes back, a callback is triggered to finish that processing.
Non-blocking I/O can provide far superior CPU utilization since you're just triggering calls and registering callbacks and not having to try to balance the "right" number of concurrent threads which are mostly just sleeping anyways.
Is the hierarchy important?
You're probably better off using an ExecutorService with a cached thread pool.
That way you can pool threads instead of creating lots (which is expensive). ExecutorServices also provide other cool things, and using Callables / Runnables with them is probably much easier to test than mucking about with threads on your own.
Upvotes: 1
Reputation: 2790
I would not prefer this way because:
*Less readable
*Thread 2 automatically will pick thread 1 priority unless you dont set manually
*Thread scheduler JVM based (like time slices, queuing...) so you dont know when thread 1 will pass the runnable state
*If thread 2 relies on thread 1 you can achieve this target using wait and notify or other new features so it will be more readable
Upvotes: 1
Reputation: 5387
There are no inner Threads in any programming language. Threads are just objects with a run()
method with the feature that several Threads can run at the same time (concurrently).
In your example, you create two Threads inside the run()
method of a Thread. That is not a problem since you can create Objects in any context.
If you want to use the Threads, you have to call outer.start()
, inner1.start()
and inner2.start()
after creating the Threads, otherwise they aren't executed. Again, that's absolutely fine because it doesn't matter in which context a Thread is started; all Threads are treated equally by the Java Virtual Machine.
Upvotes: 2
Reputation: 31182
according to Q1 "is it good". It's correct, however does not make much sense to create a threat only to create another threads.
Also, keep in mind, that creating a Thread object is relatively expensive operation.
You have //some statements and other inner threads
comment in your code. Consider using ThreadPoolExecutor to avoid creating many Threads manually.
Upvotes: 1