一个 J2EE 应用程序可以利用多个 JVM，以提高应用程序的可靠性和性能。为了在最终用户中将多个 JVM 显示为单个的应用程序，J2EE 容器可以在多个 JVM 之间复制 HttpSession 对象，所以当一个 JVM 不可用时，另一个 JVM 可以在不中断应用程序流程的情况下接替步骤的执行。

为了使会话复制能够正常运行，作为应用程序属性存储在会话中的数值必须实现 Serializable 接口。

例 1：下面这个类把自己添加到会话中，但由于它不是可序列化的，因此该会话就再也不能被复制了。

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

J2EE 标准禁止在某些环境下使用 Web 应用程序中的线程管理，因为此时使用线程管理非常容易出错。线程管理起来很困难，并且可能还会以不可预知的方式干扰应用程序容器。即使容器没有受到干扰，线程管理通常还会导致各种难以发现的错误，如死锁、race condition 及其他同步错误等。

与 block.timestamp 或 block.number 关联的值通常由开发人员用于触发与时间相关的事件，但是，这些值通常给人以一种此类时间使用起来不太安全的感觉。

由于区块链的去中心化性质，节点只能在一定程度上同步时间。使用 block.timestamp 说的好听点是不可靠，在最坏的情况下，恶意矿工如果看到这样做的好处，则会改变其区块的时间戳。

至于 block.number，即使可以预测区块之间的时间（大约 14 秒），区块时间也不恒定，可能会随着网络活动而发生变化。这使得 block.number 对于与时间相关的计算来说变得不可靠。

示例 1：以下代码使用 block.number 在一定时间后解锁资金。

function withdraw() public {
    require(users[msg.sender].amount > 0, 'no amount locked');
    require(block.number >= users[msg.sender].unlockBlock, 'lock period not over');
    uint amount = users[msg.sender].amount;
    users[msg.sender].amount = 0;
    (bool success, ) = msg.sender.call.value(amount)("");
    require(success, 'transfer failed');
}

Node.js 允许开发人员将回调分配给 IO 阻止的事件。这样可提高性能，因为回调可异步运行，从而使主应用程序不会被 IO 阻止。但是，如果回调外部的某些内容依赖于先运行的回调内的代码，这反过来会造成争用条件。

示例 1：以下代码可基于数据库对用户进行身份验证。

 
...
var authenticated = true; 
...
database_connect.query('SELECT * FROM users WHERE name == ? AND password = ? LIMIT 1', userNameFromUser, passwordFromUser, function(err, results){
  if (!err && results.length > 0){
    authenticated = true;
  }else{
    authenticated = false;
  }
});

if (authenticated){
  //do something privileged stuff
  authenticatedActions();
}else{
  sendUnathenticatedMessage();
}

在此示例中，我们应当调用到后端数据库，以确定用户用于登录的凭据，确认有效后，将变量设置为 true，否则设置为 false。令人遗憾的是，由于回调被 IO 阻止，它将异步运行且可能在检查 if (authenticated) 之后运行，由于默认值为 true，它将进入 if-statement，确认用户实际上是否已经过身份验证。

应用程序通过共享存储安装应用程序，任何具有外部存储读/写权限的应用程序都可写入到该存储。 由于存在争用情况，监控文件夹的恶意应用程序可将下载的 APK 文件交换为 APK 替换文件，安装进程会使用该替换文件取代合法更新。

示例 1： 以下代码可通过共享存储安装应用程序：

    Intent intent = new Intent(Intent.ACTION_VIEW);
    intent.setDataAndType(Uri.fromFile(new File(Environment.getExternalStorageDirectory() + "/download/" + "app.apk")), "application/vnd.android.package-archive");
    intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    startActivity(intent);

文件访问的 race condition（如已知的 time-of-check、time-of-use (TOCTOU) race condition）在以下情况中出现：

1. 程序检查某个文件的属性时，根据名称来引用文件。

2.程序稍后使用相同的文件名执行文件系统操作，并假定先前检查的属性没有改变。
示例 1：以下代码来自已安装 setuid root 的程序。该程序代表非特权用户执行某些文件操作，并使用访问检查来确保它不会使用其 root 权限执行当前用户不应该执行的操作。该程序使用 access() 系统调用来检查运行该程序的人员是否有权访问指定的文件，然后再打开该文件并执行必要的操作。

  if (!access(file,W_OK)) {
    f = fopen(file,"w+");
    operate(f);
    ...
  }
  else {
    fprintf(stderr,"Unable to open file %s.\n",file);
  }

对 access() 的调用按照预期计划的那样执行，而且如果运行程序的用户具有编辑文件的必要权限，则会返回 0，反之则会返回 -1。然而，因为 access() 和 fopen() 都是对文件名进行操作，而不是文件句柄，所以当 file 变量传递到 fopen() 时，就无法保证该变量仍能像传递到 access() 时那样引用磁盘上相同的文件。如果攻击者在调用 access() 之后，用指向其他文件的象征性链接来取代 file，程序就会使用根权限对文件进行操作，即便这个文件是攻击者在其他情况下无法进行更改的。通过欺骗程序去运行其他情况下不允许执行的操作，从而使攻击者获得更高的权限。

这种形式的漏洞不限于具有 root 权限的程序。如果应用程序能够执行本不允许攻击者执行的操作，那么有可能就会成为攻击目标。

此类攻击的漏洞窗口是测试属性和使用文件之间的时间段。即使在检查后立即使用，现代操作系统也不能保证进程挂起 CPU 之前执行的代码量。攻击者有多种技术来延长机会窗口的长度，以便更容易地利用漏洞。然而，即使窗口很小，漏洞利用尝试也可以简单地重复一遍又一遍，直到成功。

示例 2：以下代码将生成一个文件，然后更改该文件的所有者。

    fd = creat(FILE, 0644);  /* Create file */
    if (fd == -1)
        return;
    if (chown(FILE, UID, -1) < 0) {  /* Change file owner */
      ...
    }

该代码假定通过调用 chown() 操作的文件与通过调用 creat() 创建的文件是一样的，但事实未必如此。因为 chown() 根据文件名而不是文件句柄操作，攻击者可以将该文件替换为指向不归他所有的文件的链接。调用 chown() 将给予攻击者链接文件的所有权。

java.text.Format 中的 parse() 和 format() 方法包含一个可导致用户看到其他用户数据的 race condition。

示例 1：以下代码显示了此设计缺陷是如何显现出来的。

public class Common {

    private static SimpleDateFormat dateFormat;
    ...

    public String format(Date date) {
        return dateFormat.format(date);
    }
    ...

    final OtherClass dateFormatAccess=new OtherClass();
    ...

    public void function_running_in_thread1(){
        System.out.println("Time in thread 1 should be 12/31/69 4:00 PM, found: "+ dateFormatAccess.format(new Date(0)));
    }

    public void function_running_in_thread2(){
        System.out.println("Time in thread 2 should be around 12/29/09 6:26 AM, found: "+ dateFormatAccess.format(new Date(System.currentTimeMillis())));
    }
}

尽管此代码可在单一用户环境中正常运行，但如果两个线程同时运行此代码，则会生成以下输出内容：

Time in thread 1 should be 12/31/69 4:00 PM, found: 12/31/69 4:00 PM
Time in thread 2 should be around 12/29/09 6:26 AM, found: 12/31/69 4:00 PM

在这种情况下，第一个线程中的数据显示在了第二个线程的输出中，原因是实施的 format() 中存在 race condition。