Java – where to use callable and runnable interfaces?

I am a novice in Java. I am reading the concept of multithreading. I have experienced these two concepts in various implementations of multithreading

I doubt whether callable can complete all functions of runnable. Why do so many people use runnable instead of callable? Does the implementation of the callable interface have additional overhead compared to the runnable inteface?

Solution

Java. Net exists in the Java 5 distribution util. Before the concurrent package, there are actually no other options for concurrent calculation, but directly operate threads

You can directly manipulate threads, for example, by subclassing:

public class MyThread extends Thread {
    public void run() {
        mycomputation();
    }
}

Or you can do the same thing by creating a runnable, which is the preferred way (mainly because you don't need to subclass anything. It provides clear separation of concerns, better code reuse or, in general, better combination):

public class MyRunnable implements Runnable {
    public void run() {
        mycomputation();
    }
}
new Thread(new MyRunnable()).start();

But no matter which way you use, you must create, start, operate and join threads Which has disadvantages: how many threads can you create? Is this expensive? (at some point, it is, although each JVM implementation becomes cheaper and cheaper.)

In addition, the API itself has limitations that developers must overcome: what if I want to return a value from runnable and see that the signature does not allow it? How do I know if my runnable failed due to an exception? Some things, such as exception handlers, allow threads, but it is a quiet, repetitive, error prone task

Enter Java util. Concurrent package! It provides all these (and more) answers!

You want to reuse threads for multiple "units of work" (whether runnableor?): You can. Want to know if the "work unit" has completed or failed: you can Want to return a value: you can Do you want to dynamically prioritize some tasks over others? of course. Need to be able to arrange tasks? You can do it wait.

Replace your runnables with callables (it's simple, both are single method interfaces!), Stop manipulating threads to support futures and leave the pipeline to executorservice

Maybe they do have old code (Java 1.4?) Maybe they don't understand the benefits of higher-level abstraction and prefer lower-level threads?

Generally speaking, due to the emergence of concurrent APIs, there is absolutely no reason to prefer threads

In "implement callable" vs runnable, No But the cost of the new callable is costly, because internally, it will return to threads and runnables (at least, the current implementation will do so) But you may actually get performance, because new functions are like threads, which are easier to reuse!

So, yes, concurrency API has its cost, but it is absolutely and completely negligible in any standard use case, but it also has new advantages to make it better in many aspects, including performance

In addition, you have obtained a lot of new possibilities from the API (see fork / join framework, see parallel flow in Java 8,...), and reduce the demand for any kink of "custom" and "self-made". It is well known that it is difficult to achieve the concurrent code of the functions described

The benefit / cost ratio fully supports the "new" concurrency API