Java Thread用于管理套接字和运行类方法

Question

I have a Java thread that I start so it keeps listening to a socket (considering the a socket read is blocking a thread is needed).

After the Thread receives the data from the socket it needs to call a method from a class.

Now I have two options to do this:

Declare an interface that is passed to the Thread and implemented in a class. When the thread calls the interface method the implementing classes will run it.

Or I can pass the class instance to the Thread as a parameter and then call the class method.

But I wanted to know if the thread blocks while the method is running.

I suppose so but I'm not sure.

I wanted the thread to have a Socket event behavior. What I mean is to only be responsible for reading the data from the socket and fire functions in the main Class, the one that called the Thread.

Answer 1

Yes, the thread will block while executing the method, so it can not read from the socket at the same time. No information will be lost, the transfer only takes longer and you can get a socket timeout if the computation takes too long.

If your method takes much time to run, you should execute it in another worker thread. I recommend to use an Executor for that.

Answer 2

You have various options :

• Make your class a child class of Thread (easier code but you'll merge functionnal part - your main code - with a technical aspect (extending the Thread))
• Make your class implements the Runnable interface and start a new thread with that Runnable (i often do like that). So your main code still remains in a overriden run method, but the inheritance tree is up to you (your main class can extend one of your other class)
• Keep separated your main code / the thread with two classes (one for your main code, one for the thread), linking the two at your will (remember that if you make an inner thread inside another class, the inner thread can use any final properties, for example).

As stated in other answers, anything happening in your run() method is of course blocking the execution.

As a sidenote, if you're going to deal with threads and sockets, i strongly suggest you to have a look at NIO frameworks like Netty that are just there for this kind of behavior : event driven client/server application through NewIO sockets.

As another sidenote, i often use this pattern :

• start an acquisition thread that will catch the event ;
• push them in a linkedblockingqueue (queue.offer()) ;
• have another thread that shares the same linkedblockingqueue (with queue.take()) : this operation is blocking, the threads will be blocked as long as the queue is empty ;

This is a very simple way to have one thread as "producer", and one thread as "consumer". You can even have various consumers awaiting on the same queue.

Answer 3

But I wanted to know if the thread blocks while the method is running

Yes it does block.
If inside run you call a method to process something it doesn't matter if that is an interface etc as you ask it only matters what does the method actually do

In your case you have only 1 option.
Make sure that you return the control back to your socket listening thread asap.
This can happen by designing/mandating the processing class to handle the processing in a different thread.
Actually your problem is not something new. In event based designs there is the requirement to process the event as fast as possible so as to not block the event queue based flow.
And this is how I would recommend you to design arround. Not use any interface to interact with the listening thread but register an event listener(s).

When an event occurs ie your listening thread reads data, it will pass the data as event to your listener(s) at which point of course it will block.
Then you should start a new thread to do the processing and the listening thread can continue with its work