java IO流 字节流方法readUTF和writeUTF配对

java socket流遇到的奇怪的问题

      readUTF方法阻塞的原因

最近遇到这样的需求：Android端需要把一些信息发生给pc上的程序上

技术方案：数据线相连的方式进行adb通信，而adb通信的原理就是socket的通信，且服务端的ip就是 127.0.0.1
通过adb的方式pc端作为客户端，Android终端作为服务端，Android主动发过去一些信息过去

优化点：为了节约服务端的性能，只在合适的时机下启动服务端，

      方案一：监听usb链接的广播，启动Android程序
      方案二：pc客户端在启动时主动地去发送启动广播的指令

使用了方案二明显更好点

DataInputStram和DataOutputStream
由于我在服务端使用了readUTF()方法接收数据，客户端使用了writeUTF
两者可以连接上并且通信成功

但是当我使用电脑上的网络工具进行连接时，发现两者能连接，服务端在readUtf方法这里阻塞呢，所以一直没能返回数据过去
为什么writeUTF和readUTF需要成套地使用？？？

看看源码
writeUTF
首先，通过 writeShort 方法将两个字节写入输出流，表示后跟的字节数。该值是实际写出的字节数，不是字符串的长度。根据此长度，使用字符的 UTF-8 修改版编码按顺序输出字符串的每个字符。如果没有抛出异常，则计数器 written 增加写入输出流的字节总数。该值至少是 2 加 str 的长度，最多是 2 加 str 的三倍长度。
使用utf-8编码 其实就是从unicode变过来的，utf8编码把其中的ASC编码变成1个字节，其他其他字符2到3个字节

ReadUTF
读入一个已使用 UTF-8 修改版格式编码的字符串。readUTF 的常规协定是：该方法读取使用 UTF-8 修改版格式编码的 Unicode 字符串的表示形式；然后以 String 的形式返回此字符串。
首先读取两个字节，并使用它们构造一个无符号 16 位整数，构造方式与 readUnsignedShort 方法的方式完全相同。该整数值被称为 UTF 长度，它指定要读取的额外字节数。然后成组地将这些字节转换为字符。每组的长度根据该组第一个字节的值计算。紧跟在某个组后面的字节（如果有）是下一组的第一个字节。

而当客户端使用普通的write(byte[])时，可能导致readUTF方法抛异常

总结：出现问题不要慌，多加日志，断点来判断，找到阿里的问题