Java Socket正确读取数据姿势

news/2024/5/17 19:25:16 标签: socket, TCP, socket阻塞

前言

平时日常开发用得最多是Http通讯,接口调试也比较简单的,也有比较强大的框架支持(OkHttp)。
个人平时用到socket通讯的地方是Android与外设通讯,Android与ssl服务通讯,这种都是基于TCP/IP通讯,而且服务端和设备端协议都是不能修改的,只能按照相关报文格式进行通信。
但使用socket通讯问题不少,一般有两个难点:

  1. socket通讯层要自己写及IO流不正确使用,遇到读取不到数据或者阻塞卡死现象或者数据读取不完整
  2. 请求和响应报文格式多变(json,xml,其它),解析麻烦,如果是前面两种格式都简单,有对应框架处理,其它格式一般都需要自己手动处理。

本次基于第1点问题做了总结,归根结底是使用read()readLine()导致的问题

Socket使用流程

  1. 创建socket
  2. 连接socket
  3. 获取输入输出流

字节流:

   InputStream  mInputStream = mSocket.getInputStream();
   OutputStream  mOutputStream = mSocket.getOutputStream();

字符流:

  BufferedReader mBufferedReader = new BufferedReader(new InputStreamReader(mSocket.getInputStream(), "UTF-8"));
  PrintWriter mPrintWriter = new PrintWriter(new BufferedWriter(new OutputStreamWriter(mSocket.getOutputStream(), "UTF-8")), true);

至于实际使用字节流还是字符流,看实际情况使用。如果返回是字符串及读写与报文结束符(/r(0x0A)或/n(0x0D)或/r/n)有关,使用字符流读取,否则字节流。

  1. 读写数据
  2. 关闭socket
    如果是Socket短连接,上面五个步骤都要走一遍;
    如果是Socket长连接,只需关注第4点即可,第4点使用不慎就会遇到上面出现的问题。
    实际开发中,长连接使用居多,一次连接,进行多次收发数据。

特别注意:使用长连接不能读完数据后立马关闭输入输出流,必须再最后不使用的时候关闭

Socket数据读写

socket阻塞时,必须设置读取超时时间,防止调试时,socket读取数据长期挂起。

 mSocket.setSoTimeout(10* 1000);  //设置客户端读取服务器数据超时时间

使用read()读取阻塞问题

日常写法1:

 mOutputStream.write(bytes);
 mOutputStream.flush();
byte[] buffer = new byte[1024];
int n = 0;
ByteArrayOutputStream output = new ByteArrayOutputStream();
while (-1 != (n = mInputStream .read(buffer))) {
    output.write(buffer, 0, n);
}
//处理数据
  output.close();
byte[] result = output.toByteArray();

上面看似没有什么问题,但有时候会出现mInputStream .read(buffer)阻塞,导致while循环体里面不会执行
日常写法2:

mOutputStream.write(bytes);
mOutputStream.flush();
int  available = mInputStream.available();
byte[] buffer = new byte[available];
in.read(buffer);

上面虽然不阻塞,但不一定能读取到数据,available 可能为0,由于是网络通讯,发送数据后不一定马上返回。
或者对mInputStream.available()修改为:

 int available = 0;
while (available == 0) {
    available = mInputStream.available();
}

上面虽然能读取到数据,但数据不一定完整。
而且,available方法返回估计的当前流可用长度,不是当前通讯流的总长度,而且是估计值;read方法读取流中数据到buffer中,但读取长度为1至buffer.length,若流结束或遇到异常则返回-1。

最终写法(递归读取):

 /**
     * 递归读取流
     *
     * @param output
     * @param inStream
     * @param timeout  单位毫秒,看实际情况定义(如果socket通讯超时时间略长,如果用于硬件串口数据读取则略短),可以指定200毫秒,10*1000或20*1000
     * @return
     * @throws Exception
     */
    public void readStreamWithRecursion(ByteArrayOutputStream output, InputStream inStream, int timeout) throws Exception {
        long start = System.currentTimeMillis();
        while (inStream.available() == 0) {
            if ((System.currentTimeMillis() - start) > timeout) {//超时退出
                throw new SocketTimeoutException("超时读取");
            }
        }
        byte[] buffer = new byte[2048];
        int read = inStream.read(buffer);
        output.write(buffer, 0, read);
        SystemClock.sleep(100);//需要延时以下,不然还是有概率漏读
        int a = inStream.available();//再判断一下,是否有可用字节数或者根据实际情况验证报文完整性
        if (a > 0) {
            LogUtils.w("========还有剩余:" + a + "个字节数据没读");
            readStreamWithRecursion(output, inStream,timeout);
        }
    }

    /**
     * 读取字节
     *
     * @param inStream
     * @param timeout
     * @return
     * @throws Exception
     */
    private byte[] readStream(InputStream inStream, int timeout) throws Exception {
        ByteArrayOutputStream output = new ByteArrayOutputStream();
        readStreamWithRecursion(output, inStream,timeout);
        output.close();
        int size = output.size();
        LogUtils.i("本次读取字节总数:" + size);
        return output.toByteArray();
    }

上面流读取的时候给定一个读超时时间,并在读取完成一次后,固定等待时间,等待完不一定有数据,若没有有数据,响应时间过长,会影响用户体验。我们可以再优化一下:

 /**
     * 递归读取流
     *
     * @param output
     * @param inStream
     * @param timeout
     * @return
     * @throws Exception
     */
    public void readStreamWithRecursion(ByteArrayOutputStream output, InputStream inStream, int timeout) throws Exception {
        long start = System.currentTimeMillis();
        while (inStream.available() == 0) {
            if ((System.currentTimeMillis() - start) >timeout) {//超时退出
                throw new SocketTimeoutException("超时读取");
            }
        }
        byte[] buffer = new byte[2048];
        int read = inStream.read(buffer);
        output.write(buffer, 0, read);
       int wait = readWait();
        long startWait = System.currentTimeMillis();
        boolean checkExist = false;
        while (System.currentTimeMillis() - startWait <= wait) {
            int a = inStream.available();
            if (a > 0) {
                checkExist = true;
                //            LogUtils.w("========还有剩余:" + a + "个字节数据没读");
                break;
            }

        }
        if (checkExist) {
          readStreamWithRecursion(output, inStream, timeout);
        }
        
    }
    
 /**
     * 二次读取最大等待时间,单位毫秒
     */
    protected int readWait() {
        return 100;
    }
    

    /**
     * 读取字节
     *
     * @param inStream
     * @param timeout
     * @return
     * @throws Exception
     */
    private byte[] readStream(InputStream inStream, int timeout) throws Exception {
        ByteArrayOutputStream output = new ByteArrayOutputStream();
        readStreamWithRecursion(output, inStream,timeout);
        output.close();
        int size = output.size();
        LogUtils.i("本次读取字节总数:" + size);
        return output.toByteArray();
    }

上面这种延迟率大幅降低,目前正在使用该方法读取,再也没有出现数据读取不完整和阻塞现象。不过这种,读取也要注意报文结束符问题,何时读取完毕问题。

细心的朋友可以发现上面适合于客服端主动向服务端发起请求响应处理(一问一答),不适合做监听服务端数据处理,监听还得轮询阻塞方式处理,可以参考文章最后的链接。

上面字节流readStreamWithRecursion方法使用备注:

  • 如果是socket通讯建议设置mSocket.setSoTimeout读超时时间,readStreamWithRecursion方法读取超时时间小于SoTimeout
  • 如果是用于硬件通讯流数据读取,非常合适,可以对发送的任意指令设置读取超时间时间

补充

如果你实际Socket通讯数据包格式是有一定规则的,可以把InputStream、OutputStream 分别装饰成 DataOutputStreamDataOutputStream

public DataInputStream(InputStream in) { super(in);}
public DataOutputStream(OutputStream out) { super(out); }

这样更方便读写数据,边读边解析数据,转成相应的基本Java数据类型。这与上面使用read()一次性读取数据到ByteArrayOutputStream ,然后根据byte[]提取相应的数据。不过这两种方式各有优缺点,看具体情况使用。

关于这两个DataOutputStreamDataOutputStream的具体用法参考文章全网最全的Java Socket通讯例子

使用readreadLine()读取阻塞问题

日常写法:

 mPrintWriter.print(sendData+ "\r\n");   
 mPrintWriter.flush();
 String msg = mBufferedReader.readLine();
 //处理数据
 

细心的你发现,发送数据时添加了结束符,如果不加结束符,导致readLine()阻塞,读不到任何数据,最终抛出SocketTimeoutException异常

特别注意:
报文结束符:根据实际服务器规定的来添加,必要时问后端开发人员或者看接口文档是否有说明
不然在接口调试上会浪费很多宝贵的时间,影响后期功能开发。

使用readLine()注意事项:

  1. 读入的数据要注意有/r或/n或/r/n
    这句话意思是服务端写完数据后,会打印报文结束符/r或/n或/r/n;
    同理,客户端写数据时也要打印报文结束符,这样服务端才能读取到数据。
  2. 没有数据时会阻塞,在数据流异常或断开时才会返回null
  3. 使用socket之类的数据流时,要避免使用readLine(),以免为了等待一个换行/回车符而一直阻塞

上面长连接是发送一次数据和读一次数据,保证了当次通讯的完整性,必须要时需要同步处理。
也有长连接,客户端开线程循环阻塞等待服务端数据发送数据过来,比如:消息推送。平时使用长连接都是分别使用不同的命令发送数据且接收数据,来完成不同的任务。

总结

实际开发中,长连接比较复杂,还要考虑心跳,丢包,断开重连等问题。使用长连接时,要特别注意报文结束符问题,结束符只是用来告诉客户端或服务端数据已经发送完毕,客户端或服务端可以读取数据了,否则客户端或服务端会一直阻塞在read()或者readLine()方法。

其它文章:

全网最全的Java Socket通讯例子


http://www.niftyadmin.cn/n/533985.html

相关文章

利用Python进行数据分析(9) pandas基础: 汇总统计和计算

pandas 对象拥有一些常用的数学和统计方法。 例如&#xff0c;sum() 方法&#xff0c;进行列小计&#xff1a; sum() 方法传入 axis1 指定为横向汇总&#xff0c;即行小计&#xff1a; idxmax() 获取最大值对应的索引&#xff1a; 还有一种汇总是累计型的&#xff0c;cumsum()&…

Java获取类或接口上的泛型类型T方法

前言 实际开发中&#xff0c;泛型使用到处可见。有时候定义接口时&#xff0c;经常使用泛型&#xff0c;而不是指定具体对象&#xff0c;使用泛型的好处很多&#xff0c;特别是代码复用方面。要获取类或接口上的泛型类型Class<?>&#xff0c;然后对这个类型进行数据处理…

非常棒的Android开源UI库、类库、项目汇总

前言 平时Android开发为了按时按质完成任务&#xff0c;总少不了一手好资源&#xff0c;这样不仅大幅提高开发效率&#xff08;说不定老板还会为你加薪升职&#xff09;&#xff0c;又可以把开发剩出的时间用来学习其它技术&#xff0c;一举两得。当然如果你时间充足且有一定的…

jps命令使用

jps工具 jps(Java Virtual Machine Process Status Tool)是JDK 1.5提供的一个显示当前所有java进程pid的命令&#xff0c;简单实用&#xff0c;非常适合在linux/unix平台上简单察看当前java进程的一些简单情况。jps(Java Virtual Machine Process Status Tool)是JDK 1.5提供的一…

Android基于Http服务实现文件管理器

前言 大家都知道手机自带的文件管理都有一个远程管理文件的功能&#xff0c;都是基于FTP服务实现&#xff0c;只要电脑端和手机端在同一局域网里&#xff0c;就可以访问手机里的文件&#xff0c;但是发现这种FTP远程文件管理有缺点&#xff1a;响应比较慢且整个页面刷新。本文…

传说中的WCF(9):流与文件传输

在使用Socket/TCP来传输文件&#xff0c;弄起来不仅会有些复杂&#xff0c;而且较经典的“粘包”问题有时候会让人火冒七丈。如果你不喜欢用Socket来传文件&#xff0c;不妨试试WCF&#xff0c;WCF的流模式传输还是相当强大和相当实用的。 因为开启流模式是基于绑定的&#xff…

一款牛逼的Android端身份证合成工具

简介 做物联网设备软件开发时&#xff0c;设备端一般都有读取ID Card的模块&#xff0c;比如银行自助终端&#xff0c;图书馆自助端&#xff0c;而从硬件端读取ID Card出来的是原始数据&#xff0c;需要合成ID Card正反面并在终端显示&#xff0c;最终上传base64编码的图片数据…

基于RxJava2.0+Retrofit2.0超大文件分块(分片)上传(带进度)

当上传文件过大时&#xff0c;直接上传会增加服务器负载&#xff0c;负载过高会导致机器无法处理其他请求及操作&#xff0c;甚至导致宕机&#xff0c;这时分块上传是最佳选择。本次简单介绍两种分块上传文件方案&#xff08;暂不考虑文件安全相关问题&#xff0c;如签名&#…