伺服器上發現批量執行狀態查詢有時會報系統未知錯誤，然後查詢日誌發現，batch端返回的rejcode=null，導致mweb無法識別錯誤型別。
但是為什麼rejcode會等於null呢？
跟蹤**發現，batchtemplate裡面有乙個try catch，在catch裡面會給rejcode重新賦值，所以驗證try裡面的**
try catch (throwable t) catch (throwable t1)
context.setdata("_responserejmsg", msg); }
發現只有execute報空指標錯誤才能將rejcode賦值為null
跟蹤發現super.execute執行的是jobstatusqryaction
在這個action裡面有兩個地方有可能會引起空指標，所以增加日誌
if (jobid != null && jobid.length() > 0) else
} else
else }
} }} }
context.setdata("joblist", joblist);
context.setdata("jobloglist", jobloglist); }
發現此處標紅**會引起空指標。為什麼這裡會空指標呢？
經排查發現是由於batch處理併發時，效率太低，引起死迴圈，導致此處remove為空
private mapjobmap = new hashmap();// 已初始化未完成的批量
private mapjobmap = new concurrenthashmap();// 已初始化未完成的批量
將此處hashmap改為concurrenthashmap
為什麼此處不能用hashmap？因為hashmap執行緒不安全，在多執行緒環境下，使用hashmap進行put操作會引起死迴圈，導致cpu利用率接近100%，所以在併發情況下不能使用hashmap。
以下來自網上摘抄：
hashtable容器在競爭激烈的併發環境下表現出效率低下的原因，是因為所有訪問hashtable的執行緒都必須競爭同一把鎖，那假如容器裡有多把鎖，每一把鎖用於鎖容器其中一部分資料，那麼當多執行緒訪問容器裡不同資料段的資料時，執行緒間就不會存在鎖競爭，從而可以有效的提高併發訪問效率，這就是concurrenthashmap所使用的鎖分段技術，首先將資料分成一段一段的儲存，然後給每一段資料配一把鎖，當乙個執行緒占用鎖訪問其中乙個段資料的時候，其他段的資料也能被其他執行緒訪問。
大致意思就是：concurrenthashmap將資料分段儲存，並對每段資料都分配了一把鎖，這樣執行緒就有多條路，也不會在一條路上堵塞，引起崩潰。
另外在解決這個問題的時候發現manifest.mf檔案裡面有乙個很有意思的引數
csii-autostart: true //如果為ture則pe部署平台的普通使用者可以在batch的包列表裡面可見，預設為false 只有管理員sysadmin使用者可見
csii-startlevel: 8 //包啟動級別，級別低的啟動優先。
mysql 執行狀態
show processlist 或使用mysql administrator 檢視當前執行connection的狀態 state列出的狀態主要有以下幾種 checking table 正在檢查資料表 這是自動的 closing tables 正在將表中修改的資料重新整理到磁碟中，同時正在關閉已經用...
程序執行狀態
程序是乙個動態的實體，所以他是有生命的。從建立到消亡，是乙個程序的整個生命週期。在這個週期中，程序可能會經歷各種不同的狀態。一般來說，所有程序都要經歷以下的3個狀態 就緒態。指程序已經獲得所有所需的其他資源，正在申請處理處理器資源，準備開始執行。這種情況下，稱程序處於就緒態。阻塞態。指程序因為需要等...
linux Shell 查詢服務執行狀態相關命令
ps ef grep servername.jar grep v grep awk 備註 grep v grep 含義是過濾掉grep 程序 awk 含義是按空格或tab分割，輸出第2項 kill 9 pid ps ef grep servername.jar grep v grep wc l 備註...