java零碎要点009---java实现服务器心跳机制,TCP握手

心跳机制是定时发送一个自定义的结构体(心跳包)，让对方知道自己还活着，以确保连接的有效性的机制。

应用场景：

在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接，保活

什么是心跳机制？

就是每隔几分钟发送一个固定信息给服务端，服务端收到后回复一个固定信息如果服务端几分钟内没有收到客户端信息则视客户端断开。

发包方：可以是客户也可以是服务端，看哪边实现方便合理。 心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40秒比较不错。如果实在要求高，那就在6-9秒。

心跳包的发送，通常有两种技术：

1.应用层自己实现的心跳包

由应用程序自己发送心跳包来检测连接是否正常，服务器每隔一定时间向客户端发送一个短小的数据包，然后启动一个线程，在线程中不断检测客户端的回应， 如果在一定时间内没有收到客户端的回应，即认为客户端已经掉线；同样，如果客户端在一定时间内没有收到服务器的心跳包，则认为连接不可用。

2.使用SO_KEEPALIVE套接字选项

在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项. 不论是服务端还是客户端，一方开启KeepAlive功能后，就会自动在规定时间内向对方发送心跳包， 而另一方在收到心跳包后就会自动回复，以告诉对方我仍然在线。因为开启KeepAlive功能需要消耗额外的宽带和流量，所以TCP协议层默认并不开启默认的KeepAlive超时需要7,200，000 MilliSeconds， 即2小时，探测次数为5次。对于很多服务端应用程序来说，2小时的空闲时间太长。因此，我们需要手工开启KeepAlive功能并设置合理的KeepAlive参数

开启KeepAlive选项后会导致的三种情况：

1、对方接收一切正常：以期望的ACK响应，2小时后，TCP将发出另一个探测分节

2、对方已崩溃且已重新启动：以RST响应。套接口的待处理错误被置为ECONNRESET，套接口本身则被关闭。

3、对方无任何响应：套接口的待处理错误被置为ETIMEOUT，套接口本身则被关闭.

有关SO_KEEPALIVE的三个参数:

1.tcp_keepalive_intvl，保活探测消息的

发送频率

。默认值为75s。

发送频率tcp_keepalive_intvl乘以发送次数tcp_keepalive_probes，就得到了从开始探测直到放弃探测确定连接断开的时间，大约为11min。

2.tcp_keepalive_probes，TCP发送保活探测消息以确定连接是否已断开的

次数

。默认值为9（次）。

3.tcp_keepalive_time，在TCP保活打开的情况下，最后一次数据交换到TCP发送第一个保活探测消息的时间，即允许的持续

空闲时间

。默认值为7200s（2h）

  长连接的维持，是要客户端程序，定时向服务端程序，发送一个维持连接包的。
       如果，长时间未发送维持连接包，服务端程序将断开连接。

客户端：
       Client通过持有Socket的对象，可以随时（使用sendObject方法）发送Massage Object(消息)给服务端。
       如果keepAliveDelay毫秒（程序中是2秒）内未发送任何数据，则自动发送一个KeepAlive Object(心跳)给服务端，用于维持连接。
       由于，我们向服务端，可以发送很多不同的消息对象，服务端也可以返回不同的对象。所以，对于返回对象的处理，要编写具体的ObjectAction实现类进行处理。通过Client.addActionMap方法进行添加。这样，程序会回调处理。

服务端：
        由于客户端会定时（keepAliveDelay毫秒）发送维持连接的信息过来，所以，服务端要有一个检测机制。
        即当服务端receiveTimeDelay毫秒（程序中是3秒）内未接收任何数据，则自动断开与客户端的连接。
         ActionMapping的原理与客户端相似（相同）。

         通过添加相应的ObjectAction实现类，可以实现不同对象的响应、应答过程。

Demo:

 package socket.keepalive.test;


 import java.io.Serializable;
 import java.text.SimpleDateFormat;
 import java.util.Date;

 /**
  *
  * 维持连接的消息对象（心跳对象）
  */
 public class KeepAlive implements Serializable{

     private static final long serialVersionUID = -2813120366138988480L;

     /* 覆盖该方法，仅用于测试使用。
      * @see java.lang.Object#toString()
      */
     @Override
     public String toString() {
         return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date())+"\t维持连接包";
     }

 }

 

 package socket.keepalive.test;

 import java.io.IOException;
 import java.io.InputStream;
 import java.io.ObjectInputStream;
 import java.io.ObjectOutputStream;
 import java.net.Socket;
 import java.net.UnknownHostException;
 import java.util.Collections;
 import java.util.concurrent.ConcurrentHashMap;

 /**
  *  C/S架构的客户端对象，持有该对象，可以随时向服务端发送消息。
  * <p>
  * 创建时间：2010-7-18 上午12:17:25
  * @author HouLei
  * @since 1.0
  */
 public class Client {

     /**
      * 处理服务端发回的对象，可实现该接口。
      */
     public static interface ObjectAction{
         void doAction(Object obj,Client client);
     }

     public static final class DefaultObjectAction implements ObjectAction{
         public void doAction(Object obj,Client client) {
             System.out.println("处理：\t"+obj.toString());
         }
     }


     public static void main(String[] args) throws UnknownHostException, IOException {
         String serverIp = "127.0.0.1";
         int port = 65432;
         Client client = new Client(serverIp,port);
         client.start();
     }

     private String serverIp;
     private int port;
     private Socket socket;
     private boolean running=false; //连接状态

     private long lastSendTime; //最后一次发送数据的时间

     //用于保存接收消息对象类型及该类型消息处理的对象
     private ConcurrentHashMap<Class, ObjectAction> actionMapping = new ConcurrentHashMap<Class,ObjectAction>();

     public Client(String serverIp, int port) {
         this.serverIp=serverIp;
         this.port=port;
     }

     public void start() throws UnknownHostException, IOException {
         if(running)return;
         socket = new Socket(serverIp,port);
         System.out.println("本地端口："+socket.getLocalPort());
         lastSendTime=System.currentTimeMillis();
         running=true;
         new Thread(new KeepAliveWatchDog()).start();  //保持长连接的线程，每隔2秒项服务器发一个一个保持连接的心跳消息
         new Thread(new ReceiveWatchDog()).start();    //接受消息的线程，处理消息
     }

     public void stop(){
         if(running)running=false;
     }

     /**
      * 添加接收对象的处理对象。
      * @param cls 待处理的对象，其所属的类。
      * @param action 处理过程对象。
      */
     public void addActionMap(Class<Object> cls,ObjectAction action){
         actionMapping.put(cls, action);
     }

     public void sendObject(Object obj) throws IOException {
         ObjectOutputStream oos = new ObjectOutputStream(socket.getOutputStream());
         oos.writeObject(obj);
         System.out.println("发送：\t"+obj);
         oos.flush();
     }

     class KeepAliveWatchDog implements Runnable{
         long checkDelay = 10;
         long keepAliveDelay = 2000;
         public void run() {
             while(running){
                 if(System.currentTimeMillis()-lastSendTime>keepAliveDelay){
                     try {
                         Client.this.sendObject(new KeepAlive());
                     } catch (IOException e) {
                         e.printStackTrace();
                         Client.this.stop();
                     }
                     lastSendTime = System.currentTimeMillis();
                 }else{
                     try {
                         Thread.sleep(checkDelay);
                     } catch (InterruptedException e) {
                         e.printStackTrace();
                         Client.this.stop();
                     }
                 }
             }
         }
     }

     class ReceiveWatchDog implements Runnable{
         public void run() {
             while(running){
                 try {
                     InputStream in = socket.getInputStream();
                     if(in.available()>0){
                         ObjectInputStream ois = new ObjectInputStream(in);
                         Object obj = ois.readObject();
                         System.out.println("接收：\t"+obj);
                         ObjectAction oa = actionMapping.get(obj.getClass());
                         oa = oa==null?new DefaultObjectAction():oa;
                         oa.doAction(obj, Client.this);
                     }else{
                         Thread.sleep(10);
                     }
                 } catch (Exception e) {
                     e.printStackTrace();
                     Client.this.stop();
                 }
             }
         }
     }

 }

 

 package socket.keepalive.test;


 import java.io.IOException;
 import java.io.InputStream;
 import java.io.ObjectInputStream;
 import java.io.ObjectOutputStream;
 import java.net.ServerSocket;
 import java.net.Socket;
 import java.util.concurrent.ConcurrentHashMap;

 /**
  * C/S架构的服务端对象。
  * <p>
  * 创建时间：2010-7-18 上午12:17:37
  * @author HouLei
  * @since 1.0
  */
 public class Server {

     /**
      * 要处理客户端发来的对象，并返回一个对象，可实现该接口。
      */
     public interface ObjectAction{
         Object doAction(Object rev, Server server);
     }

     public static final class DefaultObjectAction implements ObjectAction{
         public Object doAction(Object rev,Server server) {
             System.out.println("处理并返回："+rev);
             return rev;
         }
     }

     public static void main(String[] args) {
         int port = 65432;
         Server server = new Server(port);
         server.start();
     }

     private int port;
     private volatile boolean running=false;
     private long receiveTimeDelay=3000;
     private ConcurrentHashMap<Class, ObjectAction> actionMapping = new ConcurrentHashMap<Class,ObjectAction>();
     private Thread connWatchDog;

     public Server(int port) {
         this.port = port;
     }

     public void start(){
         if(running)return;
         running=true;
         connWatchDog = new Thread(new ConnWatchDog());
         connWatchDog.start();
     }

     @SuppressWarnings("deprecation")
     public void stop(){
         if(running)running=false;
         if(connWatchDog!=null)connWatchDog.stop();
     }

     public void addActionMap(Class<Object> cls,ObjectAction action){
         actionMapping.put(cls, action);
     }

     class ConnWatchDog implements Runnable{
         public void run(){
             try {
                 ServerSocket ss = new ServerSocket(port,5);
                 while(running){
                     Socket s = ss.accept();
                     new Thread(new SocketAction(s)).start();
                 }
             } catch (IOException e) {
                 e.printStackTrace();
                 Server.this.stop();
             }

         }
     }

     class SocketAction implements Runnable{
         Socket s;
         boolean run=true;
         long lastReceiveTime = System.currentTimeMillis();
         public SocketAction(Socket s) {
             this.s = s;
         }
         public void run() {
             while(running && run){
                 if(System.currentTimeMillis()-lastReceiveTime>receiveTimeDelay){
                     overThis();
                 }else{
                     try {
                         InputStream in = s.getInputStream();
                         if(in.available()>0){
                             ObjectInputStream ois = new ObjectInputStream(in);
                             Object obj = ois.readObject();
                             lastReceiveTime = System.currentTimeMillis();
                             System.out.println("接收：\t"+obj);
                             ObjectAction oa = actionMapping.get(obj.getClass());
                             oa = oa==null?new DefaultObjectAction():oa;
                             Object out = oa.doAction(obj,Server.this);
                             if(out!=null){
                                 ObjectOutputStream oos = new ObjectOutputStream(s.getOutputStream());
                                 oos.writeObject(out);
                                 oos.flush();
                             }
                         }else{
                             Thread.sleep(10);
                         }
                     } catch (Exception e) {
                         e.printStackTrace();
                         overThis();
                     }
                 }
             }
         }

         private void overThis() {
             if(run)run=false;
             if(s!=null){
                 try {
                     s.close();
                 } catch (IOException e) {
                     e.printStackTrace();
                 }
             }
             System.out.println("关闭："+s.getRemoteSocketAddress());
         }

     }

 }

     TCP提供了一种面向连接的、可靠的字节流服务。面向连接比较好理解，就是连接双方在通信前需要预先建立一条连接，这犹如实际生活中的打电话。助于可靠性，TCP协议中涉及了诸多规则来保障通信链路的可靠性，总结起来，主要有以下几点：

      （1）应用数据分割成TCP认为最适合发送的数据块。这部分是通过“MSS”（最大数据包长度）选项来控制的，通常这种机制也被称为一种协商机制，MSS规定了TCP传往另一端的最大数据块的长度。值得注意的是，MSS只能出现在SYN报文段中，若一方不接收来自另一方的MSS值，则MSS就定为536字节。一般来讲，在不出现分段的情况下，MSS值还是越大越好，这样可以提高网络的利用率。

      （2）重传机制。设置定时器，等待确认包。

      （3）对首部和数据进行校验。

      （4）TCP对收到的数据进行排序，然后交给应用层。

      （5）TCP的接收端丢弃重复的数据。

      （6）TCP还提供流量控制。

TCP报文：

（1）TCP封装数据的格式：

（2）TCP首部的格式：

 TCP首部报文格式的说明：

     （1）每个TCP段都包括源端和目的端的端口号，用于寻找发送端和接收端的应用进程。这两个值加上IP首部的源端IP地址和目的端IP地址唯一确定一个TCP连接。
     （2）序号用来标识从TCP发送端向接收端发送的数据字节流，它表示在这个报文段中的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。
     （3）当建立一个新连接时，SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN，该主机要发送数据的第一个字节的序号为这个ISN加1，因为SYN标志使用了一个序号。
     （4）既然每个被传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当时上次已成功收到数据字节序号加1。只有ACK标志为1时确认序号字段才有效。
     （5）发送ACK无需任何代价，因为32位的确认序号字段和ACK标志一样，总是TCP首部的一部分。因此一旦一个连接建立起来，这个字段总是被设置，ACK标志也总是被设置为1。
     （6）TCP为应用层提供全双工的服务。因此，连接的每一端必须保持每个方向上的传输数据序号。
     （7）TCP可以表述为一个没有选择确认或否认的华东窗口协议。因此TCP首部中的确认序号表示发送方已成功收到字节，但还不包含确认序号所指的字节。当前还无法对数据流中选定的部分进行确认。
     （8）首部长度需要设置，因为任选字段的长度是可变的。TCP首部最多60个字节。
     （9）6个标志位中的多个可同时设置为1
         URG－紧急指针有效
         ACK－确认序号有效
         PSH－接收方应尽快将这个报文段交给应用层
         RST－重建连接
         SYN－同步序号用来发起一个连接
         FIN－发送端完成发送任务
     （10）TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端期望接收的字节数。窗口大小是一个16为的字段，因而窗口大小最大为65535字节。
     （11）检验和覆盖整个TCP报文端：TCP首部和TCP数据。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。TCP检验和的计算和UDP首部检验和的计算一样，也使用伪首部。
     （12）紧急指针是一个正的偏移量，黄蓉序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。
     （13）最常见的可选字段是最长报文大小MMS，每个连接方通常都在通信的第一个报文段中指明这个选项。它指明本端所能接收的最大长度的报文段。

TCP三次握手与四次挥手全过程：

1、建立连接协议（三次握手）
    （1）客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。
    （2） 服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。
    （3） 客户必须再次回应服务段一个ACK报文，这是报文段3。


TCP的三次握手可以通过报文来分析：

   （1）客户端向服务器端发起同步请求，服务器侧端口固定为 102，客户端端口由 socket 随机产生


     （2）服务器端向客户端响应，同时也向客户端发起同步请求

     （3）客户端予以确认

2 连接终止协议（四次挥手）

　 　由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
　（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段4）。
　（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。
　（3） 服务器关闭客户端的连接，发送一个FIN给客户端（报文段6）。
　（4） 客户段发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。

通过Java代码实现TCP连接三次握手和四次挥手的过程：


package com.zhaoming.test;

import java.io.BufferedReader;
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;
import java.net.UnknownHostException;
import java.text.SimpleDateFormat;
import java.util.Date;


public class ClientConnect extends Thread
{
    //定义一个Client的对象
    private Client client;
    
    private Socket socket;
    //定义IP和端口号是常量
    private static final String IP = "192.168.1.190";
    
    private static final int PORT = 20108;
  //声明str是一个静态变量，
    public static String str = null;
    //进行构造（持有另一个类对象的引用）    
    public ClientConnect(Client client)
    {
        this.client = client;
    }
    //启用线程，处理连接
    public void run() 
    {
        try
        {
            //初始化要连接的socket套接字
            socket = new Socket(IP,PORT);
            client.getjButton1().setEnabled(false);
        }
        catch (UnknownHostException e1)
        {
            e1.printStackTrace();
        }
        catch (IOException e1)
        {
            e1.printStackTrace();
        }
        //从服务器端通过socket读取信息
        BufferedReader br = null;
        try 
        {
            br = new BufferedReader(new InputStreamReader(socket.getInputStream()));
            //把读到的信息显示到TextArea中
            while (true) 
            {
                str = br.readLine();
                client.getjTextArea1().append(str + "\n");
                //建一个新的文本文档，用于存储从服务器读到的信息
                File file = new File("E:/temperatrue.txt");
                
                PrintWriter out = null;
                String date = null;
                //修改时间显示的格式
                SimpleDateFormat sdf = null;
                
                try 
                {
                    //把读到的信息，写到到文本文件中存储起来
                    out = new PrintWriter(new FileOutputStream(file, true));
                    sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
                    date = sdf.format(new Date());
                    out.println(date+"\t"+str);
                    out.flush();
                } 
                catch (FileNotFoundException e) 
                {
                    e.printStackTrace();
                } 
                finally
                {
                    out.close();    
                }
                }
        } catch (IOException e)
        {
            e.printStackTrace();
        } 
        //进行流关闭处理，先进行判断，然后再关闭
        finally 
        {
            try
            {
                if(br != null)
                {
                    br.close();
                    br =null;
                }
                if(socket != null)
                {
                    socket.close();
                    socket = null;
                }
            } 
            catch (IOException e) 
            {
                e.printStackTrace();
            }
        }
    }
}
      由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
      TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。 
简单说来是 “先关读，后关写”，一共需要四个阶段。以客户机发起关闭连接为例：
     1.服务器读通道关闭
     2.客户机写通道关闭
     3.客户机读通道关闭
     4.服务器写通道关闭
      关闭行为是在发起方数据发送完毕之后，给对方发出一个FIN（finish）数据段。直到接收到对方发送的FIN，且对方收到了接收确认ACK之后，双方的数据通信完全结束，过程中每次接收都需要返回确认数据段ACK。

什么是心跳包？

心跳包就是在客户端和服务器间定时通知对方自己状态的一个自己定义的命令字，按照一定的时间间隔发送，类似于心跳，所以叫做心跳包。

　　 
用来判断对方（设备，进程或其它网元）是否正常运行，采用定时发送简单的通讯包，如果在指定时间段内未收到对方响应，则判断对方已经离线。用于检测TCP的异常断开。基本原因是服务器端不能有效的判断客户端是否在线，也就是说，服务器无法区分客户端是长时间在空闲，还是已经掉线的情况。所谓的心跳包就是客户端定时发送简单的信息给服务器端告诉它我还在而已。代码就是每隔几分钟发送一个固定信息给服务端，服务端收到后回复一个固定信息如果服务端几分钟内没有收到客户端信息则视客户端断开。

比如有些通信软件长时间不使用，要想知道它的状态是在线还是离线就需要心跳包，定时发包收包。发包方：可以是客户也可以是服务端，看哪边实现方便合理，一般是客户端。服务器也可以定时发心跳下去。一般来说，出于效率的考虑，是由客户端主动向服务器端发包，而不是服务器向客户端发。客户端每隔一段时间发一个包，使用TCP的，用send发，使用UDP的，用sendto发，服务器收到后，就知道当前客户端还处于“活着”的状态，否则，如果隔一定时间未收到这样的包，则服务器认为客户端已经断开，进行相应的客户端断开逻辑处理。

服务器实现心跳机制的两种策略

大部分CS的应用需要心跳机制。心跳机制一般在Server和Client都要实现，两者实现原理基本一样。Client不关心性能，怎么做都行。

如果应用是基于TCP的，可以简单地通过SO_KEEPALIVE实现心跳。TCP在设置的KeepAlive定时器到达时向对端发一个检测TCP segment，如果没收到ACK或RST，尝试几次后，就认为对端已经不存在，最后通知应用程序。这里有个缺点是，Server主动发出检测包，对性能有点影响。

应用自己实现

Client启动一个定时器，不断发心跳；

Server收到心跳后，给个回应；

Server启动一个定时器，判断Client是否存在，判断方法这里列两种：时间差和简单标志。

1. 时间差策略

收到一个心跳后，记录当前时间(记为recvedTime)。

判断定时器时间到达，计算多久没收到心跳的时间(T)=当前时间 - recvedTime(上面记录的时间)。如果T大于某个设定值，就可以认为Client超时了。

2. 简单标志

收到一个心跳后，设置连接标志为true；

判断定时器时间到达，查看所有的标志，false的，认为对端超时了；true的将其设成false。

上面这种方法比上面简单一些，但检测某个Client是否离线的误差有点大。

您还有心跳吗？超时机制分析

问题描述

在C/S模式中，有时我们会长时间保持一个连接，以避免频繁地建立连接，但同时，一般会有一个超时时间，在这个时间内没发起任何请求的连接会被断开，以减少负载，节约资源。并且该机制一般都是在服务端实现，因为client强制关闭或意外断开连接，server端在此刻是感知不到的，如果放到client端实现，在上述情况下，该超时机制就失效了。本来这问题很普通，不太值得一提，但最近在项目中看到了该机制的一种糟糕的实现，故在此深入分析一下。

问题分析及解决方案

服务端一般会保持很多个连接，所以，一般是创建一个定时器，定时检查所有连接中哪些连接超时了。此外我们要做的是，当收到客户端发来的数据时，怎么去刷新该连接的超时信息？

最近看到一种实现方式是这样做的:

public class Connection {
    private long lastTime;
    public void refresh() {
        lastTime = System.currentTimeMillis();
    }

    public long getLastTime() {
        return lastTime;
    }
    //......
}
     
     
     
     

      
      
      
      
1
      
      
      
      
2
      
      
      
      
3
      
      
      
      
4
      
      
      
      
5
      
      
      
      
6
      
      
      
      
7
      
      
      
      
8
      
      
      
      
9
      
      
      
      
10
      
      
      
      
11
     
     
     
     
     
     
     
     

      
      
      
      
1
      
      
      
      
2
      
      
      
      
3
      
      
      
      
4
      
      
      
      
5
      
      
      
      
6
      
      
      
      
7
      
      
      
      
8
      
      
      
      
9
      
      
      
      
10
      
      
      
      
11
     
     
     
     

在每次收到客户端发来的数据时，调用refresh方法。

然后在定时器里，用当前时间跟每个连接的getLastTime()作比较，来判定超时:

public class TimeoutTask  extends TimerTask{
    public void run() {
        long now = System.currentTimeMillis();
        for(Connection c: connections){
            if(now - c.getLastTime()> TIMEOUT_THRESHOLD)
                ;//timeout, do something
        }
    }
}
     
     
     
     

      
      
      
      
1
      
      
      
      
2
      
      
      
      
3
      
      
      
      
4
      
      
      
      
5
      
      
      
      
6
      
      
      
      
7
      
      
      
      
8
      
      
      
      
9
     
     
     
     
     
     
     
     

      
      
      
      
1
      
      
      
      
2
      
      
      
      
3
      
      
      
      
4
      
      
      
      
5
      
      
      
      
6
      
      
      
      
7
      
      
      
      
8
      
      
      
      
9
     
     
     
     

看到这，可能不少读者已经看出问题来了，那就是内存可见性问题，调用refresh方法的线程跟执行定时器的线程肯定不是一个线程，那run方法中读到的lastTime就可能是旧值，即可能将活跃的连接判定超时，然后被干掉。

有读者此时可能想到了这样一个方法，将lastTime加个volatile修饰，是的，这样确实解决了问题，不过，作为服务端，很多时候对性能是有要求的，下面来看下在我电脑上测出的一组数据，测试代码如下，供参考

public class PerformanceTest {
    private static long i;
    private volatile static long vt;
    private static final int TEST_SIZE = 10000000;

    public static void main(String[] args) {
        long time = System.nanoTime();
        for (int n = 0; n < TEST_SIZE; n++)
            vt = System.currentTimeMillis();
        System.out.println(-time + (time = System.nanoTime()));
        for (int n = 0; n < TEST_SIZE; n++)
            i = System.currentTimeMillis();
        System.out.println(-time + (time = System.nanoTime()));
        for (int n = 0; n < TEST_SIZE; n++)
            synchronized (PerformanceTest.class) {
            }
        System.out.println(-time + (time = System.nanoTime()));
        for (int n = 0; n < TEST_SIZE; n++)
            vt++;
        System.out.println(-time + (time = System.nanoTime()));
        for (int n = 0; n < TEST_SIZE; n++)
            vt = i;
        System.out.println(-time + (time = System.nanoTime()));
        for (int n = 0; n < TEST_SIZE; n++)
            i = vt;
        System.out.println(-time + (time = System.nanoTime()));
        for (int n = 0; n < TEST_SIZE; n++)
            i++;
        System.out.println(-time + (time = System.nanoTime()));
        for (int n = 0; n < TEST_SIZE; n++)
            i = n;
        System.out.println(-time + (time = System.nanoTime()));
    }
}
     
     
     
     

      
      
      
      
1
      
      
      
      
2
      
      
      
      
3
      
      
      
      
4
      
      
      
      
5
      
      
      
      
6
      
      
      
      
7
      
      
      
      
8
      
      
      
      
9
      
      
      
      
10
      
      
      
      
11
      
      
      
      
12
      
      
      
      
13
      
      
      
      
14
      
      
      
      
15
      
      
      
      
16
      
      
      
      
17
      
      
      
      
18
      
      
      
      
19
      
      
      
      
20
      
      
      
      
21
      
      
      
      
22
      
      
      
      
23
      
      
      
      
24
      
      
      
      
25
      
      
      
      
26
      
      
      
      
27
      
      
      
      
28
      
      
      
      
29
      
      
      
      
30
      
      
      
      
31
      
      
      
      
32
      
      
      
      
33
      
      
      
      
34
     
     
     
     
     
     
     
     

      
      
      
      
1
      
      
      
      
2
      
      
      
      
3
      
      
      
      
4
      
      
      
      
5
      
      
      
      
6
      
      
      
      
7
      
      
      
      
8
      
      
      
      
9
      
      
      
      
10
      
      
      
      
11
      
      
      
      
12
      
      
      
      
13
      
      
      
      
14
      
      
      
      
15
      
      
      
      
16
      
      
      
      
17
      
      
      
      
18
      
      
      
      
19
      
      
      
      
20
      
      
      
      
21
      
      
      
      
22
      
      
      
      
23
      
      
      
      
24
      
      
      
      
25
      
      
      
      
26
      
      
      
      
27
      
      
      
      
28
      
      
      
      
29
      
      
      
      
30
      
      
      
      
31
      
      
      
      
32
      
      
      
      
33
      
      
      
      
34
     
     
     
     

测试一千万次，结果是（耗时单位：纳秒，包含循环本身的时间）： 
238932949 volatile写+取系统时间 
144317590 普通写+取系统时间 
135596135 空的同步块（synchronized） 
80042382 volatile变量自增 
15875140 volatile写 
6548994 volatile读 
2722555 普通自增 
2949571 普通读写

从上面的数据看来，volatile写+取系统时间的耗时是很高的，取系统时间的耗时也比较高，跟一次无竞争的同步差不多了，接下来分析下如何优化该超时时机。

首先：同步问题是肯定得考虑的，因为有跨线程的数据操作；另外，取系统时间的操作比较耗时，能否不在每次刷新时都取时间？因为刷新调用在高负载的情况下很频繁。如果不在刷新时取时间，那又该怎么去判定超时？

我想到的办法是，在refresh方法里，仅设置一个volatile的boolean变量reset（这应该是成本最小的了吧，因为要处理同步问题，要么同步块，要么volatile，而volatile读在此处是没什么意义的），对时间的掌控交给定时器来做，并为每个连接维护一个计数器，每次加一，如果reset被设置为true了，则计数器归零，并将reset设为false（因为计数器只由定时器维护，所以不需要做同步处理，从上面的测试数据来看，普通变量的操作，时间成本是很低的），如果计数器超过某个值，则判定超时。 下面给出具体的代码：

public class Connection {
    int count = 0;
    volatile boolean reset = false;
    public void refresh() {
        if (reset == false)
            reset = true;
    }
}

public class TimeoutTask extends TimerTask {
    public void run() {
        for (Connection c : connections) {
            if (c.reset) {
                c.reset = false;
                c.count = 0;
            } else if (++c.count >= TIMEOUT_COUNT)
                ;// timeout, do something
        }
    }
}
     
     
     
     

      
      
      
      
1
      
      
      
      
2
      
      
      
      
3
      
      
      
      
4
      
      
      
      
5
      
      
      
      
6
      
      
      
      
7
      
      
      
      
8
      
      
      
      
9
      
      
      
      
10
      
      
      
      
11
      
      
      
      
12
      
      
      
      
13
      
      
      
      
14
      
      
      
      
15
      
      
      
      
16
      
      
      
      
17
      
      
      
      
18
      
      
      
      
19
      
      
      
      
20
     
     
     
     
     
     
     
     

      
      
      
      
1
      
      
      
      
2
      
      
      
      
3
      
      
      
      
4
      
      
      
      
5
      
      
      
      
6
      
      
      
      
7
      
      
      
      
8
      
      
      
      
9
      
      
      
      
10
      
      
      
      
11
      
      
      
      
12
      
      
      
      
13
      
      
      
      
14
      
      
      
      
15
      
      
      
      
16
      
      
      
      
17
      
      
      
      
18
      
      
      
      
19
      
      
      
      
20
     
     
     
     

代码中的TIMEOUT_COUNT 等于超时时间除以定时器的周期，周期大小既影响定时器的执行频率，也会影响实际超时时间的波动范围（这个波动，第一个方案也存在，也不太可能避免，并且也不需要多么精确）。

代码很简洁，下面来分析一下。

reset加上了volatile，所以保证了多线程操作的可见性，虽然有两个线程都对变量有写操作，但无论这两个线程怎么穿插执行，都不会影响其逻辑含义。

再说下refresh方法，为什么我在赋值语句上多加了个条件？这不是多了一次volatile读操作吗？我是这么考虑的，高负载下，refresh会被频繁调用，意味着reset长时间为true，那么加上条件后，就不会执行写操作了，只有一次读操作，从上面的测试数据来看，volatile变量的读操作的性能是显著优于写操作的。只不过在reset为false的时候，多了一次读操作，但此情况在定时器的一个周期内最多只会发一次，而且对高负载情况下的优化显然更有意义，所以我认为加上条件还是值得的。

————————————- 
补充一下：一般情况下，也可用特定的心跳包来刷新，而不是每次收到消息都刷新，这样一来，刷新频率就很低了，也就没必要太在乎性能开销。