java 处理tcp超时优化
来源:互联网 发布:手机wifi控制器软件 编辑:程序博客网 时间:2024/06/05 19:32
您还有心跳吗?超时机制分析
问题描述
在C/S模式中,有时我们会长时间保持一个连接,以避免频繁地建立连接,但同时,一般会有一个超时时间,在这个时间内没发起任何请求的连接会被断开,以减少负载,节约资源。并且该机制一般都是在服务端实现,因为client强制关闭或意外断开连接,server端在此刻是感知不到的,如果放到client端实现,在上述情况下,该超时机制就失效了。本来这问题很普通,不太值得一提,但最近在项目中看到了该机制的一种糟糕的实现,故在此深入分析一下。
问题分析及解决方案
服务端一般会保持很多个连接,所以,一般是创建一个定时器,定时检查所有连接中哪些连接超时了。此外我们要做的是,当收到客户端发来的数据时,怎么去刷新该连接的超时信息?
最近看到一种实现方式是这样做的:
01
public
class
Connection {
02
private
long
lastTime;
03
public
void
refresh() {
04
lastTime = System.currentTimeMillis();
05
}
06
07
public
long
getLastTime() {
08
return
lastTime;
09
}
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修饰,是的,这样确实解决了问题,不过,作为服务端,很多时候对性能是有要求的,下面来看下在我电脑上测出的一组数据,测试代码如下,供参考
01
public
class
PerformanceTest {
02
private
static
long
i;
03
private
volatile
static
long
vt;
04
private
static
final
int
TEST_SIZE =
10000000
;
05
06
public
static
void
main(String[] args) {
07
long
time = System.nanoTime();
08
for
(
int
n =
0
; n < TEST_SIZE; n++)
09
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(因为计数器只由定时器维护,所以不需要做同步处理,从上面的测试数据来看,普通变量的操作,时间成本是很低的),如果计数器超过某个值,则判定超时。 下面给出具体的代码:
01
public
class
Connection {
02
int
count =
0
;
03
volatile
boolean
reset =
false
;
04
public
void
refresh() {
05
if
(reset ==
false
)
06
reset =
true
;
07
}
08
}
09
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的时候,多了一次读操作,但此情况在定时器的一个周期内最多只会发一次,而且对高负载情况下的优化显然更有意义,所以我认为加上条件还是值得的。
最后提及一下,我有点完美主义,自认为上面的方案在我当前掌握的知识下,已经很漂亮了,如果你发现还有可优化的地方,或更好的方案,希望能分享。
————————————-
补充一下:一般情况下,也可用特定的心跳包来刷新,而不是每次收到消息都刷新,这样一来,刷新频率就很低了,也就没必要太在乎性能开销
- java 处理tcp超时优化
- TCP连接超时处理
- TCP超时处理
- tcp连接超时处理
- TCP/UDP select超时处理
- JAVA处理线程超时
- JAVA 超时中断处理
- JAVA处理线程超时
- JAVA HttpURLConnection超时处理
- JAVA处理线程超时
- java线程超时处理
- JAVA处理线程超时
- JAVA处理线程超时
- Java任务超时处理
- JAVA线程的超时处理
- socket 连接超时处理 java
- SNMP4J包 TCP-无超时-网络中断 处理的BUG
- java 接口方法超时异常处理 设置超时时间
- HTTP_X_FORWARDED_FOR获取到的IP地址
- 朴素贝叶斯算法学习笔记(一)
- ZYNQ系统中实现FAT32文件系统的SD卡读写 之二 VIVADO配置
- 【二十】Docker安装与卸载
- SpringBoot配置属性中文释义NoSQL(四)
- java 处理tcp超时优化
- 关于目标检测和目标跟踪的一个小疑惑
- SpringBoot配置属性中文释义MQ(五)
- sphinx 增量索引 实现近实时
- [HNOI2004]L语言
- SpringBoot配置属性中文释义Security(六)
- 理解unix 系统I/O --csapp读书笔记
- mybatis 的延迟加载
- JVM调优系列:(三)类加载和执行机制