2

I am making a server, and the server creates a thread for each client that connects. That thread will have an open inputstream which it will monitor for incoming messages. The Runnable of that thread will be called ServerListenerRunnable for this example.

I am conflicted whether to use Executor or just run the thread straight away.

For example

Runnable listener = new ServerListenerRunnable();
Executor executor = Executors.newSingleThreadExecutor();
executor.execute(listener);

Is this somehow better than just running

new Thread(new ServerListenerRunnable()).start();

And can you tell me why?

And if you have some time to kill, can you explain in general why using Executor is better than running the thread straight away or vice versa.

Thank you in advance.

efronberlian
  • 23
  • 6
  • There a nothing wrong with using a executor in this way, as it gives you experience with using the API - IMHO – MadProgrammer Mar 09 '14 at 06:58
  • Why is it even necessary for your server to create a thread? Maybe a simpler (e. g. evented) approach does the job? – Oliver Jan Krylow Mar 09 '14 at 16:30
  • @OJKrylow what do you mean if I really need to create threads? I need to handle each client separately with threads. There is no other way unless I only wanted to accept one client. And can you explain what you mean by evented approach? I am making something like a web service server with java where a client can connect and retrieve data. The server can also be modified for something like a chatting server. I would love to know if there is an alternate way of doing this. – efronberlian Mar 10 '14 at 02:03

4 Answers4

2

Even if you only use one Runnable in the entire existence of your program, it is still better to use an Executor for a simple reason: it is about the same amount of code to write, and should you ever feel like changing your program, you have the threading part done already.

So you loose nothing but gain flexibility. And flexibility is - if you work on a professional level - the most valuable thing. Because there is always that one day, where you boss bursts into your room and demands a last minute change. Good programmers prepare for that, bad programmers cancel their evening plans. ;)

TwoThe
  • 13,879
  • 6
  • 30
  • 54
1

I think your main concern is why executor framework is better then using thread.Below para form Thinking in java book gives perfect explanation for this

Java SE5 java.util.concurrent Executors simplify concurrent programming by managing Thread objects for you. Executors provide a layer of indirection between a client and the execution of a task; instead of a client executing a task directly, an intermediate object executes the task. Executors allow you to manage the execution of asynchronous tasks without having to explicitly manage the lifecycle of threads. Executors are the preferred method for starting tasks in Java SE5/6

We don't kill thread as kill() method is deprecated and will not be available in JDK 8. To stop processing we send interrupt to thread. in Thread approach Using thread.interrupt() and in executor framework using shutdownnow() And then we handle interrupt in run() method to come out of it.

Also I am not aware of any case when thread is preferred approach. Let's see if someone posts any example when we prefer thread over executor.

Community
  • 1
  • 1
Vipin
  • 4,851
  • 3
  • 35
  • 65
0

Even when it is a single thread executor it can execute multiple tasks using the same thread. With the second option we need to create a new Thread for each task which is less efficient.

Evgeniy Dorofeev
  • 133,369
  • 30
  • 199
  • 275
0

As mentioned in my comment, you should first of all determine if your use case even benefits from a threaded server. It is not the only way to handle multiple clients :) See for example this blog entry for a discussion about the two main stream approaches to web server implementation right now.

Now, assuming you decided threads are the way to go, and coming back to your original question; It seems to me that your server manages (creates) threads and now you are simply contemplating how to invoke the logic a thread is supposed to execute. So in a very real sense your server is an Executor, you are just rolling your own implementation of it, instead of using the provided one.

If my assumptions are correct, executing the Runnable via a SingleThreadExecutor is absolutely over-complicating it, because now your server has to manage the executor (instead of a thread), so you introduced a level of abstraction for no apparent gain. Unless you see the possibility, that in the future, it might be required, that you need to spawn multiple threads per client, I would advice against it.

Rather, have your server extend or delegate to an Executor with a fixed thread pool size and just pass it the Runnable. That way you profit from the Java Concurrency API.

Oliver Jan Krylow
  • 1,758
  • 15
  • 22