為了提高應用程式的可靠性和性能，一個 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 應用程式中進行執行緒管理，且執行緒管理非常容易發生錯誤。管理執行緒非常困難，並且可能會以無法預測的方式干擾應用程式容器的運作。即使容器沒有受到干擾，執行緒管理通常還是會發生錯誤，例如無法偵測並診斷鎖死 (deadlock)、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 陳述式。

應用程式會從共用儲存區安裝應用程式，任何具有外部儲存區讀取/寫入權限的應用程式都可以寫入該儲存區。 由於競爭情形，監控資料夾的惡意應用程式可針對替代 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);

File access race condition (也稱為 time-of-check)、time-of-use (TOCTOU) race conditions，在以下情況中出現：

1. 程式檢查檔案特性時，根據名稱來參照檔案。

2.程式稍後會使用相同的檔案名稱執行檔案系統作業，並假設先前檢查的屬性並未變更。
範例 1：以下程式碼來自一個安裝了 setuid 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，第一個執行緒的日期會在第二個執行緒的輸出中顯示。