关于DataInputStream.read(byte[])阻塞和非阻塞
翻开jdk,赫然写着:
public final int read(byte[] b) throws IOException
从包含的输入流中读取一定数量的字节,并将它们存储到缓冲区数组 b 中。以整数形式返回实际读取的字节数。在输入数据可用、检测到文件末尾 (end of file) 或抛出异常之前,此方法将一直阻塞。
可是经过某些测试后我们惊奇的发现, 这个DataInputStream.read(byte[]) 并非阻塞的. 在一个长连接的socket通道上,读完数据之前 他就已经解除阻塞了,从而造成后面的报文发生粘包现象...而这个现象在PC上怎么都测试不出来, 一上真机的j2me环境就出了....
最后没办法. 我们采取 for循环一个固定length. 然后 一个字节 一个字节的读到 byte[]里.
但是问题是: 没道理啊. jdk上明明写着:检测到文件末尾 (end of file) 或抛出异常之前,此方法将一直阻塞
谁能帮忙解释,指导一下呢?
[解决办法]
没遇见过这种情况
[解决办法]
楼主对API理解的非常正确,现实中,也是这样的。
可能是细节上面出了错误。
出现后面粘包现象,可能是由于,前面没有读取到足够的数据。
我们编程的时候,一般都用public final int read(byte b[], int off, int len) throws IOException
这个方法。
而楼主的那个方法,需要IO将参数缓冲区填满才返回,
这就有两种情况:
一:缓冲区的大小,比数据包小。
这样,实际上读取的是个半包,当然,一般后面程序会出现异常。
二:缓冲区的大小,比数据包大。
这样,实际上读取的是一个整包加一个半包。
这时,后面的程序,有可能只处理了那个整包的数据,缓冲区中的半包数据没有被处理,被丢弃了。
上述两种状况,都会引起后面的粘包现象。
所以,在知道包长度的情况下,使用我说的那个方法来读取数据,可以有效控制所读数据的长度。
楼主再仔细查查,一般都是由我说的第二种情况引起的。
[解决办法]