游戏服务器定时任务大家是通过什么方式实现的

这个是我在网上找的不知道是不是你要的：

java定时任务Timer 关于定时任务，似乎跟时间操作的联系并不是很大，但是前面既然提到了定时任务，索性在这里一起解决了。设置定时任务很简单，用Timer类就搞定了。一、延时执行首先，我们定义一个类，给它取个名字叫TimeTask，我们的定时任务，就在这个类的main函数里执行。代码如下：

package test

import java.util.Timer

public class TimeTaskTest {

public static void main(String[] args){ Timer timer = new Timer()

timer.schedule(new Task(), 60 * 1000)

}

}

解释一下上面的代码。上面的代码实现了这样一个功能，当TimeTask程序启动以后，过一分钟后执行某项任务。很简单吧：先new一个Timer对象，然后调用它的schedule方法，这个方法有四个重载的方法，这里我们用其中一个，

public void schedule(TimerTask task,long delay)

首先，第一个参数第一个参数就是我们要执行的任务。这是一个TimerTask对象，确切点说是一个实现TimerTask的类的对象，因为TimerTask是个抽象类。上面的代码里 面，Task就是我们自己定义的实现了TimerTask的类，因为是在同一个包里面，所以没有显性的import进来。Task类的代码如下

package test

import java.util.TimerTask

public class Task extends TimerTask { public void run()

{

System.out.println("定时任务执行")

}

}

我们的Task必须实现TimerTask的方法run，要执行的任务就在这个run方法里面，这里，我们只让它往控制台打一行字。第二个参数第二个参数是一个long型的值。这是延迟的时间，就是从程序开始以后，再过多少时间来执行定时任务。这个long型的值是毫秒数，所以前面我们的程序里面，过一分钟后执行用的参数值就是 60 * 1000。二、循环执行设置定时任务的时候，往往我们需要重复的执行这样任务，每隔一段时间执行一次，而上面的方法是只执行一次的，这样就用到了schedule方法的是另一个重载函数public void schedule(TimerTask task,long delay,long period)

前两个参数就不用说什么了，最后一个参数就是间隔的时间，又是个long型的毫秒数（看来java里涉及到时间的，跟这个long是脱不了干系了），比如我们希望上面的任务从第一次执行后，每个一分钟执行一次，第三个参数值赋60 * 1000就ok了。三、指定执行时间既然号称是定时任务，我们肯定希望由我们来指定任务指定的时间，显然上面的方法就不中用了，因为我们不知道程序什么时间开始运行，就没办法确定需要延时多少。没关系，schedule四个重载的方法还没用完呢。用下面这个就OK了：

public void schedule(TimerTask task,Date time)

比如，我们希望定时任务2006年7月2日0时0分执行，只要给第二个参数传一个时间设置为2006年7月2日0时0分的Date对象就可以了。有一种情况是，可能我们的程序启动的时候，已经是2006年7月3日了，这样的话，程序一启动，定时任务就开始执行了。schedule最后一个重载的方法是public void schedule(TimerTask task,Date firstTime,long period)

没必要说什么了吧:)四、j2ee中的定时任务在实际的项目中，往往定时任务需要对web工程中的资源进行操作，这样一来，用上面的单个程序的方式可能就有点力不从心了，因为很多web工程的资源它操作不到。解决的办法是，使用Servlet，把执行定时任务的那些代码放到Servlet的init()函数里就可以了，这个easy，就没有必要再写示例代码了吧

在平时的开发中，经常会碰到一些需要检测tcp连接是否正常的场景。比如一个分布式的应用，一个调度任务的节点管理一堆用来跑业务的节点。当调度节点进行调度的时候，需要把任务分发给它认为正常的业务节点去执行。业务节点是否正常，一个重要的参考依据就是调度节点和业务节点之间的tcp连接是否正常。这时候就需要调度节点主动地去检测tcp连接。常见的检测方法有以下几种

方案一、通过TCP协议的返回值进行判断

<1>利用select，把socket设置为非阻塞。然后使用select等待该socket的可读事件。如果socket可读，但是recv的返回值是0，则说明socket已经被对端断开，这时候就可以调用close关闭socket。这里还要注意一点，recv还可能返回负数，这个代表socket操作出错。但是仍然应该判断一下errno是否为EINTR。如果errno是EINTR，则说明recv函数是被信号中断返回的，这时候不能判断socket的连接是否正常，也不应该调用close关闭socket。

<2>利用poll的事件。poll本身提供了POLLHUP，POLLERR, POLLNVAL三个事件。如果文件描述符是socket，则POLLHUP代表socket已经断开了连接，在TCP底层就是已经收到了FIN报文。POLLERR表示socket出现了错误，一般情况下是收到了rst报文，或者已经发送了rst报文。这两种情况都应该调用close关闭socket。POLLNVAL代表socket没有打开，这时不能使用close关闭它，而应该根据自己的业务做一些其他的操作。因为关闭一个未打开的socket会出错。

这两种方法都可以很精确地判断tcp连接是否正常，但是仍然有很明显的缺陷。就是它只可以根据TCP操作的返回值来进行判断。如果TCP四次握手没有正常被执行呢？比如连接对端机器直接挂了，那么就不会发送FIN报文给这一端，select不会返回socket可读，poll不会返回socket异常。那么这个死链接将会永远检测不到。直到写这个socket的时候，对端直接返回一个ret报文，这时才知道这个连接已经断掉了。这就意味着tcp连接异常可能永远检测不到，或者检测到的延迟非常大。这对于一些资源宝贵而且要求高性能的服务器是不能接受的，比如游戏服务器，比如搜索服务器。

方案二、在第一种方案的基础上设置socket的 keep alive 机制

方案一的主要缺陷在于检测不及时，或者根本检测不到。TCP协议提供了keep alive机制。如果开启了这个特性（暂时称开启了keep alive的一端为开启端），在默认情况下，开启的着一端的socket相关结构中会维护一个定时器，默认是2小时。如果在2小时内两端没有数据往来，那么开启端就会给另一端发送一个ack空报文。这时候分几种情况：

<1>对端机器可达，而且TCP相关组件运行正常。那么对端就会给开启端发送一个ack空报文。这时开启端就知道对端是正常的，意味着tcp连接也没有问题。开启端会重新初始化定时器，等待下一个超时的到来。需要注意的是，如果两端之间有数据往来，定时器也会被重新初始化为2个小时。

<2>对端挂了，或者正在重启，还没有完全起来。或者对端服务器不可达。 这种状态的对端是不会响应这个ack的。开启端的 keep alive 机制会把这种情况当探测超时来处理，并且重新发送ack到对端。当超时次数超过一定限制，keep alive 就认为这个tcp连接有问题。典型值是每次75秒，超时9次。

<3>对端挂过，但是已经重启完成。这时候发送这个ack和写已经关闭的socket是一种情况，对端会返回一个rst报文，这样开启端就知道tcp连接出问题了。

可以看出 keep alive 机制弥补了方案一种不能判断没有进行正常四次挥手连接出现问题的缺陷。默认的发送超时和发送间隔都是可以调整的。

tcp_keepalive_time: KeepAlive的空闲时长，默认是2小时

tcp_keepalive_intvl: KeepAlive探测包的发送间隔，默认是75s　

tcp_keepalive_probes: 在tcp_keepalive_time之后，没有接收到对方确认，继续发送保活探测包次数，默认是9次

这3个参数使用 setsockopt函数都是可以配置的。

方案二看似已经完美了，能够比较精确而且及时地发现有问题的连接。但是还有2个缺点。第一个是 keep alive 机制看似牛逼，但是很多人不建议使用。因为上面说的3个参数很难根据业务场景给出合适的值，设置不好很容易对tcp连接状态发生误判，关闭了一个本来正常的连接。而且没有一个主动通知应用层的方式。比如socket连接出错了，TCP协议接到了rst，fin，或者keep alive判断出socket有问题了，但是并不会主动去通知应用层，必须我们自己 recv socket或者等待错误事件才能得到这个错误。第二个是很多场景下，keep alive 检测仍然不够及时，比如对端挂了，最长需要等待 tcp_keepalive_intvl * tcp_keepalive_probes时间才可以检测出来，而且这两个值还不能设置得太小，太小了容易误判。

方案三、应用层的心跳

这种形式的心跳设计就比较多样化了，而且灵活，可以很好地适应业务场景。唯一的缺点就是要自己写代码。我目前接触到的就是定期进行RPC调用。看RPC调用是否正常，如果返回错误或者抛出异常，就说明连接有问题。

---