码迷，mamicode.com
首页 > 其他好文 > 详细

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

时间：2015-05-07 12:33:22      阅读：137      评论：0      收藏：0      [点我收藏+]

标签：android   google   java学习   java面试题   java   

问题描述

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

问题分析及解决方案

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

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

  1. public class Connection {
  2.         private long lastTime;
  3.         public void refresh() {
  4.                 lastTime = System.currentTimeMillis();
  5.         }

  7.         public long getLastTime() {
  8.                 return lastTime;
  9.         }
  10.         //......
  11. }
复制代码

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

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

  1. public class TimeoutTask  extends TimerTask{
  2.         public void run() {
  3.                 long now = System.currentTimeMillis();
  4.                 for(Connection c: connections){
  5.                         if(now - c.getLastTime()> TIMEOUT_THRESHOLD)
  6.                                 ;//timeout, do something
  7.                 }
  8.         }
  9. }
复制代码

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

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

  1. public class PerformanceTest {
  2.         private static long i;
  3.         private volatile static long vt;
  4.         private static final int TEST_SIZE = 10000000;

  6.         public static void main(String[] args) {
  7.                 long time = System.nanoTime();
  8.                 for (int n = 0; n < TEST_SIZE; n++)
  9.                         vt = System.currentTimeMillis();
  10.                 System.out.println(-time + (time = System.nanoTime()));
  11.                 for (int n = 0; n < TEST_SIZE; n++)
  12.                         i = System.currentTimeMillis();
  13.                 System.out.println(-time + (time = System.nanoTime()));
  14.                 for (int n = 0; n < TEST_SIZE; n++)
  15.                         synchronized (PerformanceTest.class) {
  16.                         }
  17.                 System.out.println(-time + (time = System.nanoTime()));
  18.                 for (int n = 0; n < TEST_SIZE; n++)
  19.                         vt++;
  20.                 System.out.println(-time + (time = System.nanoTime()));
  21.                 for (int n = 0; n < TEST_SIZE; n++)
  22.                         vt = i;
  23.                 System.out.println(-time + (time = System.nanoTime()));
  24.                 for (int n = 0; n < TEST_SIZE; n++)
  25.                         i = vt;
  26.                 System.out.println(-time + (time = System.nanoTime()));
  27.                 for (int n = 0; n < TEST_SIZE; n++)
  28.                         i++;
  29.                 System.out.println(-time + (time = System.nanoTime()));
  30.                 for (int n = 0; n < TEST_SIZE; n++)
  31.                         i = n;
  32.                 System.out.println(-time + (time = System.nanoTime()));
  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（因为计数器只由定时器维护，所以不需要做同步处理，从上面的测试数据来看，普通变量的操作，时间成本是很低的），如果计数器超过某个值，则判定超时。 下面给出具体的代码：

  1. public class Connection {
  2.         int count = 0;
  3.         volatile boolean reset = false;
  4.         public void refresh() {
  5.                 if (reset == false)
  6.                         reset = true;
  7.         }
  8. }

  10. public class TimeoutTask extends TimerTask {
  11.         public void run() {
  12.                 for (Connection c : connections) {
  13.                         if (c.reset) {
  14.                                 c.reset = false;
  15.                                 c.count = 0;
  16.                         } else if (++c.count >= TIMEOUT_COUNT)
  17.                                 ;// timeout, do something
  18.                 }
  19.         }
  20. }
复制代码

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

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

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

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

最后提及一下，我有点完美主义，自认为上面的方案在我当前掌握的知识下，已经很漂亮了，如果你发现还有可优化的地方，或更好的方案，希望能分享。
————————————-
补充一下：一般情况下，也可用特定的心跳包来刷新，而不是每次收到消息都刷新，这样一来，刷新频率就很低了，也就没必要太在乎性能开销。

原创文章，转载请注明： 转载自并发编程网 – ifeve.com

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

标签：android   google   java学习   java面试题   java   

原文地址：http://blog.csdn.net/u014714340/article/details/45557965
踩
(0)
赞
(0)
   
举报
评论 一句话评论（0）
登录后才能评论！
分享档案
更多>
2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)
周排行
mamicode.com排行更多图片
更多
友情链接
兰亭集智   国之画   百度统计   站长统计   阿里云   chrome插件   新版天听网
关于我们 - 联系我们 - 留言反馈
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码！