I have a java program which has threads that connects to a TCP server and tries to do a blocking read on the socket. The server is not sending anything on the sockets I was seeing all these threads on the profiler and saw all these threads showed as RUNNING Did a thread dump to find that these threads are in RUNNABLE state.
On a blocking read on the socket( basically waiting for network I/O) the thread state should be BLOCKED or WAITING right?
Instead when they show up as RUNNABLE, this means that cpu time slices are being wasted on this thread?
A couple years ago I tested Thread.getState() in various IO blocking situations, and I found that it seemed that some IO classes never come up WAITING or BLOCKED, while others use those frequently. At the moment I don't remember which classes did which.
I think this may be implementation-dependent. Many IO classes rely on native methods, and those methods have ways to block without wasting machine cycles, but also without using Java's synchronization or wait() method. The problem of having a process block until an IO device is ready existed long before Java, after all, and solutions were found. So from the JVM's perspective, those methods may always show up as RUNNABLE or RUNNING, never WAITING or BLOCKED - even though they are, in fact, blocking, in a wider (non-Java-threads) sense of the term. Meanwhile some other implementations (or other IO classes entirely) may use WAITING or BLOCKED just as you'd expect.
You may be able to tell from the source code - if a class explicitly uses synchronized blocks, wait(), and/or java.util.concurrent techniques, then you can expect to see WAITING or BLOCKING as states. But if the class does most work in native methods, you can't tell without looking at that native code (which is generally harder to find and understand, and in some cases completely unavailable) - and there's a very good chance that the native methods did not rely on Java's threading utilities. [ August 03, 2008: Message edited by: Mike Simmons ]
Joined: Aug 01, 2008
You are right about that. But in my case, the server is not sending anything over, even then it the thread which is blocked on socket read shows up as in RUNNABLE state. I know you might be wondering what I am trying to do here.. I wrote this small program to simulate what a real world application at work was doing, while trying to identify bottlenecks. The application that i am talking about opens a reader and writer thread each for every new socket connection opened. There are other threads running in the application for other purposes as well.What I have observed is this is not a scalable way of handling connections.With almost 1000 threads around in a deployment scenario , the time taken between the all the context switches could slow things down and causing thread starvation for one thread. While trying to figure this out, saw the threads which are on blocked read calls shown up as RUNNABLE state. After all the exploration on this topic, I think way to go would be with threadpools and NIO [ August 03, 2008: Message edited by: Pradeep nayar ]
Joined: Aug 01, 2008
Thanks for the answer Mike, I agree it should definitely be a mismatch of reporting the states between JVM and the underlying native implementations. I will try to see what the underlying code for this class does Thanks Pradeep [ August 03, 2008: Message edited by: Pradeep nayar ]