防止JAVA程序重复启动的一个另类解决办法

         我们项目中有一个后台任务处理程序，是java开发application，用以处理网站提交的一些批量数据文件，因为这些数据文件数据量一般都比较大，所以写了这个批量处理程序，用以异步处理这些批量数据文件。这个程序设计成插件式的，处理各种不同数据文件的功能单独作为一个插件，然后使用Spring来粘合各个组件，这样就可以很方便地对该程序进行扩展。
        今天客户提出一个要求：需要控制这个程序在同一主机上只能启动一个实例。
        为了实现客户要求，我首先想到就是在数据库中建一张表，程序启动时往该表中写入一个标志，等程序结束时再删除标志。但这种方式存在一个问题就是，如果程序是非正常停止或被杀进程，那么这个标志就不可能被清除，那下一次启动就会误判为重复启动；另外，如果用数据库来记录启动标志的话，还把该程序跟数据库紧密耦合起来，感觉很别扭。
        排除了第一种方案之后，我以想到了用文件来保存启动标志（好象一些大型的程序，诸如weblogic好象就是采用在文件中记录启动标志方式来控制重复启动的）。客流量然这种方式不需要与数据库耦合在一起，但也存在程序异常中止而无法清除启动标志的问题，所以这个方案也被枪毙了。
        我想到的第三种方案就是在JAVA中调用操作系统的查看系统进程的方式来取得系统进程，然后再检测系统进程有特殊的进程标志来判断是否重复启动。但这种方式一是看起来很别扭，再者就是Window和 *nix系统中查看系统进程的命令不一样，分成几种情况来处理，无端地增加了程序的复杂性，也不可取。
        能不能在内存中记录一个启动标志呢？理论上这应该是不可行的，因为跨JVM来相互操作内存数据是不可能。我在网上搜了一下，也没找到相关的例子。
        那能不能占用一点系统共享资源，来换取我们的目标呢？比较容易想到的系统资源并且不能重复使用的资源就是端口。我尝试采用如下方案：在程序中指定一个不常用的端口（比如：12345）,在程序启动时，就指定的端口启动一个ServerSocket，这个Socket只是为了占用这个端口，不接受任何网络连接。如果试图启动第二个实例时，程序在该指定端口启动ServerSocket时就会抛异常，这时我们就可以认为系统已经启动过了，然后打印提示并直接退出程序即可。这种方式在理论上分析应该可以的，我开始动手修改程序。程序修改如下：

java 代码

package cn.com.pansky.xmdswz.application.scheduler;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.quartz.SchedulerException;
import org.quartz.impl.StdScheduler;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import cn.com.pansky.xmdswz.system.cache.CachedTableMgr;
import cn.com.pansky.xmdswz.system.config.SystemConfig;
import cn.com.pansky.xmdswz.utility.DateUtil;
import org.quartz.JobDetail;
import org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean;
import java.net.ServerSocket;
import java.io.*;

/**
 * Title: XXXXXXX
 * Description: XXXXXXXXXXXX
 * Copyright: Copyright (c) 2006
 * Company: www.pansky.com.cn
 *
 * @author Sheng Youfu
 * @version 1.0
 */
public class Scheduler {
  private static Log log = LogFactory.getLog(Scheduler.class);

  private static ServerSocket srvSocket = null; //服务线程，用以控制服务器只启动一个实例

  private static final int srvPort = 12345;     //控制启动唯一实例的端口号，这个端口如果保存在配置文件中会更灵活

  /**
   * 定时任务配置文件
   */
  private static String CONFIG_FILE = "cn/com/pansky/xmdswz/application/scheduler/Scheduling-bean.xml";


  public Scheduler() {
    //检测系统是否只启动一个实例
    checkSingleInstance();

    //下面读取Spring的配置文件
    SystemConfig cfg = new SystemConfig();
    String config = cfg.parseParam("SCHEDULER.CONFIG_FILE", false);
    if(config!=null && !"".equals( config.trim()))
      CONFIG_FILE = config;
    log.debug("CONFIG_FILE: "+CONFIG_FILE);
  }

  /**
   * 主函数
   * @param args String[]
   * @throws Exception
   */
  public static void main(String[] args) throws Exception{
    Scheduler sch = new Scheduler();
    sch.execute();
  }

  /**
   * 运行定时任务
   */
  public void execute() {
    ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext(new String[] {CONFIG_FILE});
    BeanFactory factory = (BeanFactory) appContext;

    /**
     * 装载任务调度
     */
    StdScheduler scheduler = (StdScheduler) factory.getBean("schedulerFactoryBean");
    //先暂停所有任务，等待装载缓存代码表
    try {
      scheduler.pauseAll();
    } catch (SchedulerException ex) {
      log.error("",ex);
    }

    /**
     * 装载缓存代码表
     */
    CachedTableMgr cachedtableMgr = (CachedTableMgr) factory.getBean("cachedTableMgr");
    try {
      cachedtableMgr.loadCodeTable();
    } catch (Exception ex) {
      log.fatal("Load cached table failed. System will exit.", ex);
      System.exit(0);
    }

    //重新恢复所有任务
    try {
      scheduler.resumeAll();
    } catch (SchedulerException ex) {
      log.error("",ex);
    }
  }

  /**
   * 检测系统是否只启动了一个实例
   */
  protected void checkSingleInstance() {
    try {
      srvSocket = new ServerSocket(srvPort); //启动一个ServerSocket，用以控制只启动一个实例
    } catch (IOException ex) {
      if(ex.getMessage().indexOf("Address already in use: JVM_Bind")>=0)
        System.out.println("在一台主机上同时只能启动一个进程(Only one instance allowed)。");
      log.fatal("", ex);
      System.exit(0);
    }
  }
}

经过测试，程序能很好地满足我们的要求，问题解决。
         我之所以称这种方式另类，是因为这种方式以牺牲一个端口的代价来达到我们的设计要求，采用这种方式的人应该不多。但我认为，只要我们牺牲的代价与我们的目标比较起来是在可接受的范围内，这种方式就是可取的，这与我们花钱增加内存来让程序运行更快在本质应该是相同的。

评论

23 楼 hiswing 2006-12-20  

yongweiking 写道

hiswing 写道

巧了．这个思路我N年前也用过．
http://www.mxjava.com/blog/article.asp?id=3

而且最近公司的项目中也用了这个思路．呵呵～～我们都在杭州哦！

看了你写的方法，但我有一点疑问，你在选择服务器端口时，采用的是自动增加的方法，这个方法没问题，但你在console类中，iPort = 50000。由于在不同的jvm下运行，这个Consonle客户端每次连接的都是端口50000，那么，Server中端口增加非但没有意义，反而会引起误操作。假如端口50000被其它程序占用，那么该程序还不能很好做到防止重复运行了。我想还是指定端口吧。望指教。

我想你没有搞懂这个程序是做什么的。建议再认真看一遍。

22 楼 Jboss 2006-12-11  

你这个方法太old了，前几年我刚学java时就有人提过这个方法了，并不是什么“另类解决办法”。

21 楼 zgd 2006-12-11  

不另类，两个方法
首选nio锁文件
次选socket端口
已经是公认的解决方案了

20 楼 coolyzg 2006-12-11  

可以使用单例模式的一种变种

 if(instance != null) return "在一台主机上同时只能启动一个进程(Only one instance allowed)。";

19 楼 ashin 2006-12-11  

可以用访问记录。
定时记录访问时间到文件，
超时即为无程序运行或程序导常。
这样不是更容易些？

18 楼 Tao 2006-12-11  

http://www.matrix.org.cn/thread.shtml?topicId=2053&forumId=1&fid=1

17 楼 yongweiking 2006-12-09  

hiswing 写道

巧了．这个思路我N年前也用过．
http://www.mxjava.com/blog/article.asp?id=3

而且最近公司的项目中也用了这个思路．呵呵～～我们都在杭州哦！

看了你写的方法，但我有一点疑问，你在选择服务器端口时，采用的是自动增加的方法，这个方法没问题，但你在console类中，iPort = 50000。由于在不同的jvm下运行，这个Consonle客户端每次连接的都是端口50000，那么，Server中端口增加非但没有意义，反而会引起误操作。假如端口50000被其它程序占用，那么该程序还不能很好做到防止重复运行了。我想还是指定端口吧。望指教。

16 楼 wuyunlong 2006-12-08  

wdmsyf 写道

引用

Nirvana     1 小时前
我觉得利用文件来保存启动标记也可以，只是思路变换一下，打开后一个实例，强制关闭前一个：
启动实例时生成唯一标记，保存变量，写入文件，然后循环读取文件内容，判断是否与保存变量相等，不等则退出。
第二实例运行时因操作同一文件，必然会满足第一实例不等的条件，迫使第一实例关闭。

刚才做了个小实验，发现也可行。

我个人觉得Nirvana的方法不是很可行，你说在第二实例启动时，强制关闭第一实例，这存在两个问题：
1、如何做到从第二实例中关闭第一实例？
2、即使可以关闭第一实例，那第一实例中正在处理的数据咋办？而且这样强制关闭第一实例，感觉有点象病毒噢，呵呵！

我也倾向于通过锁定文件来保证java启动程序的唯一性，以前我写过一个这样的mini程序库。
关闭第一个实例是通过在程序中添加JMX接口，允许远程调用该接口来关闭程序，而不是执行kill -9这样的操作
来关闭。

15 楼 wdmsyf 2006-12-08  

引用

hiswing     7 小时前

巧了．这个思路我N年前也用过．
http://www.mxjava.com/blog/article.asp?id=3

而且最近公司的项目中也用了这个思路．呵呵～～我们都在杭州哦！

hiswing：呵呵，与我心有戚戚焉，握个手先！  

14 楼 kenny319 2006-12-08  

之前也碰到过类似的问题，这的确是一个比较好的方式。

13 楼 hiswing 2006-12-08  

巧了．这个思路我N年前也用过．
http://www.mxjava.com/blog/article.asp?id=3

而且最近公司的项目中也用了这个思路．呵呵～～我们都在杭州哦！

12 楼 Nirvana 2006-12-08  

wdmsyf 写道

引用

Nirvana     1 小时前
我觉得利用文件来保存启动标记也可以，只是思路变换一下，打开后一个实例，强制关闭前一个：
启动实例时生成唯一标记，保存变量，写入文件，然后循环读取文件内容，判断是否与保存变量相等，不等则退出。
第二实例运行时因操作同一文件，必然会满足第一实例不等的条件，迫使第一实例关闭。

刚才做了个小实验，发现也可行。

我个人觉得Nirvana的方法不是很可行，你说在第二实例启动时，强制关闭第一实例，这存在两个问题：
1、如何做到从第二实例中关闭第一实例？
2、即使可以关闭第一实例，那第一实例中正在处理的数据咋办？而且这样强制关闭第一实例，感觉有点象病毒噢，呵呵！

1.如果觉得不清楚，补充一下：第二个实例运行时，改变了同一文件所记录的启动标记，而第一个实例始终循环读取文件进行比较，此时标记变量值与文件内容不等即关闭。
这个应该很简单的。

2.请问你非正常情况下退出时，数据是怎么处理的？难道都是随它去吗？
另外，我的这关闭，应该是正常退出，尚在程序可控制范围下。
扯病毒就太远了，倒是服务器端口经常被封的说。

11 楼 Tanner 2006-12-08  

File lock 要指定文件路径,很局限,还是端口更全局一些。

10 楼 Tanner 2006-12-08  

http://www.google.com/codesearch?hl=en&q=+lang:java+file+lock+show:c7KnypL3_Ww:Pv4m6pxQY3c:7XNnTPAzhY8&sa=N&cd=1&ct=rc&cs_p=svn://source.pentaho.org/svnroot/pentaho-reportdesigner/trunk&cs_f=src/org/pentaho/reportdesigner/lib/client/util/SingleApplicationLock.java#a0

SingleApplicationLock.java
有个实现了。

9 楼 Tanner 2006-12-08  

http://www.google.com/codesearch?hl=en&q=+lang:java+file+Open+full+occupied+show:07RRbObTL2o:DFnXDE8Qjvw:dkG5HqoyK5Y&sa=N&cd=8&ct=rc&cs_p=:pserver:anonymous%40hsqldb.cvs.sourceforge.net:/cvsroot/hsqldb+hsqldb-dev3&cs_f=src/org/hsqldb/persist/NIOLockFile.java#a0
似乎有关，接着试

8 楼 Tanner 2006-12-08  

Eclipse启动似乎是通过文件来判断的，
还有Java Logging API也会产生一个.lck文件，
可不可以通过标志文件的存取权限来判断？
试试看去，10分钟后回来。

7 楼 iceboundrock 2006-12-07  

C/C++里最常规的解决方案还是用Mutex，不过这个咚咚不知道在java里有没有。

6 楼 wdmsyf 2006-12-07  

引用

Nirvana     1 小时前
我觉得利用文件来保存启动标记也可以，只是思路变换一下，打开后一个实例，强制关闭前一个：
启动实例时生成唯一标记，保存变量，写入文件，然后循环读取文件内容，判断是否与保存变量相等，不等则退出。
第二实例运行时因操作同一文件，必然会满足第一实例不等的条件，迫使第一实例关闭。

刚才做了个小实验，发现也可行。

我个人觉得Nirvana的方法不是很可行，你说在第二实例启动时，强制关闭第一实例，这存在两个问题：
1、如何做到从第二实例中关闭第一实例？
2、即使可以关闭第一实例，那第一实例中正在处理的数据咋办？而且这样强制关闭第一实例，感觉有点象病毒噢，呵呵！

5 楼 Nirvana 2006-12-07  

我觉得利用文件来保存启动标记也可以，只是思路变换一下，打开后一个实例，强制关闭前一个：
启动实例时生成唯一标记，保存变量，写入文件，然后循环读取文件内容，判断是否与保存变量相等，不等则退出。
第二实例运行时因操作同一文件，必然会满足第一实例不等的条件，迫使第一实例关闭。

刚才做了个小实验，发现也可行。

4 楼 wdmsyf 2006-12-07  

引用

complystill     20 分钟前
确实是很不错的一个方法, 绝大部分服务器系统上, 端口相对来说还是比较cheap的.

这个问题经典的跨平台解决方法是建一个命名的系统互斥量, 它的生命周期也是跟着进程的. 不过Java平台不倾向于提供直接操作宿主系统资源的途径, 自己也是以虚拟机为全部逻辑环境, 不提供宿主系统范围的Inter-JVM-Communication机制. 用端口绑定方式来实现互斥确实有点另类, 不过对于纯Java应用来说不失为最佳的解决方案.

另可以有一点改进的地方, 就是绑定到 InetAddress.getLocalHost() 这个本机地址(在大多数OS上相当于127.0.0.1), 这样进一步不会占用服务器外部ip上的端口. 不过一般的服务器上服务进程通常也不指定具体外部地址, 而是绑定到所有本机地址的端口, 即便这样改过以后还是会影响他们的启动. 所以这个改进除非在很大型的系统上, 服务应用各自指定具体的外部地址去绑定时才有作用.

谢谢各位的回复，特别是complystill和Sunteya 给我开扩了思路。
我得到的回报比我给出的多得多啊！！