❶ 伺服器老是出現停止錯誤，然後意外關閉，請問各位大俠怎麼解決
可能的原因：
一、內存錯誤
二、某個定時的服務引起死鎖
三、病毒殘留或者黑客攻擊
四、諾頓的文件檢查功能
檢查及處理過程：
一、由於這是第一次出現類似重啟，先不考慮硬體故障。 但內存錯誤仍有另外一個可能性就是對磁碟上的虛擬內存訪問出錯。先檢查虛擬內存所在磁碟，未發現錯誤。但磁碟中有比較多的文件碎片，考慮到內存文件過於分散有可能會引起偶爾的讀錯誤。所以在凌晨1時左右進行一次全盤的文件碎片整理。
二、根據原因代碼，網路上有關於定時服務引起文件死鎖的記錄，而查詢登錄日誌，離重啟最近的訪問來自於另一台伺服器B，加上出現故障時間與整點比較接近，有可能與某些系統服務有關，所以，將B中的DNS、DHCP等服務關閉，因為這些服務會與故障伺服器通訊同步，或者進行某種查詢。更進一步地，將伺服器和B伺服器上的文件跨網路定時復制備份等功能刪除。
三、從微軟的網站找到有關病毒也會引發類似故障的說明（相關網址），按說明查詢後排除可能性，然後，再檢查可疑的設備驅動，也未發現任何可疑之處。另外，通過查詢防火牆日誌，在19：03前也未發現有異常的攻擊事件。
四、通過網路上上報的事故報告（相關網址）中提到Symantec的版本有關，在Symantec的技術支持網站看到相類似的報告。考慮到離最近的故障時間登錄者是B伺服器，而我們的B伺服器上恰恰安裝了Symantec的10.0版，懷疑與故障伺服器上的9.0版在升級病毒庫時產生了沖突，所以將B上的Symantec殺毒軟體刪除，然後安裝了一個客戶端，由故障伺服器統一管理。
進一步分析
用WinDbg對系統崩潰時的內存Dump文件分析，發現系統重啟時的直接引發文件為RapDrv.sys。
這個文件為BlackICE的系統文件，它包括了監視應用程序的變化的相關模塊，可參見BlackICE的在線說明
檢查RapDrv.sys，文件沒有被改變的跡象，可排除被黑客和病毒修改文件的可能性。
對Dump文件進行調試，找到RapDrv.sys出錯時的堆棧情況，具體內容如下：
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx" "0x%08lx" "%s"
FAULTING_IP:
RapDrv+9785
f535e785 894104 mov dword ptr [ecx+4],eax
TRAP_FRAME: f4c0bb54 -- (.trap fffffffff4c0bb54)
ErrCode = 00000002
eax=858b8b4c ebx=00000000 ecx=00000000 edx=00000000 esi=858b5000 edi=84e2660c
eip=f535e785 esp=f4c0bbc8 ebp=f4c0bbdc iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
RapDrv+0x9785:
f535e785 894104 mov dword ptr [ecx+4],eax ds:0023:00000004=????????
Resetting default scope
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: blackice.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 8085b4b3 to 8087b6be
STACK_TEXT:
f4c0b720 8085b4b3 0000008e c0000005 f535e785 nt!KeBugCheckEx+0x1b
f4c0bae4 808357a4 f4c0bb00 00000000 f4c0bb54 nt!KiDispatchException+0x3a2
f4c0bb4c 80835758 f4c0bbdc f535e785 badb0d00 nt!CommonDispatchException+0x4a
f4c0bb6c f5355b93 850ab630 84e2660c 858b5001 nt!Kei386EoiHelper+0x186
WARNING: Stack unwind information not available. Following frames may be wrong.
f4c0bbdc f535aa20 85897900 84e2660c 00000028 RapDrv+0xb93
f4c0bc08 f535b282 00222034 84e26608 00000058 RapDrv+0x5a20
f4c0bc28 f535b2f3 865b5ba0 00000058 86043a70 RapDrv+0x6282
f4c0bc4c 8092d3b9 84ad79d8 858e9028 84ad7968 RapDrv+0x62f3
f4c0bc60 8092e81b 865b5ba0 84ad7968 858e9028 nt!IopSynchronousServiceTail+0x10b
f4c0bd00 80940844 00000160 00000000 00000000 nt!IopXxxControlFile+0x5db
f4c0bd34 80834d3f 00000160 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f4c0bd34 7c95ed54 00000160 00000000 00000000 nt!KiFastCallEntry+0xfc
0012d688 00000000 00000000 00000000 00000000 0x7c95ed54
STACK_COMMAND: kb
FOLLOWUP_IP:
RapDrv+9785
f535e785 894104 mov dword ptr [ecx+4],eax
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: RapDrv
IMAGE_NAME: RapDrv.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 3f99bc4f
SYMBOL_NAME: RapDrv+9785
FAILURE_BUCKET_ID: 0x8E_RapDrv+9785
BUCKET_ID: 0x8E_RapDrv+9785
Followup: MachineOwner
從上面可以看出，在系統崩潰時，RapDrv正試圖作一個IO操作，在IopSynchronousServiceTail調用時出錯。在網上查尋相關資料，發現DapDrv有一個系統漏洞（相關資料），這個漏洞目前並沒有相關補丁和解決方案，好在它發生的條件比較苛刻，如果是攻擊，必須是已經攻入系統，在試圖修改應用程序時才會觸發。也就是說，如果想用這個漏洞進行攻擊，對方必須是已經攻入系統才能利用這個漏洞。
綜合上述，原來推測的四個可能性，只有最後一個Symantec的版本問題最有可能，因為其它的文件傳輸，只要不修改伺服器上的可執行程序，是不會引發錯誤的。而Symantec在B伺服器上安裝的也是伺服器版，它的升級過程中，可能會試圖替換故障伺服器上Symantec的上的9.0版程序。這才會觸發RapDrv對文件進行監控。
目前最終處理方案是：
考慮到這種事故發生時造成的影響較小，在基本排除硬體故障後，決定暫時只處理Symantec的版本問題，然後繼續觀察伺服器的狀態，如果不再發生類似事件，則不予理會。如果再一次發生類似情況，就將BlackICE中的文件保護功能關閉，這樣可以一勞永逸地解決這類事故。
❷ JAVA程序設計，多線程且避免死鎖
JAVA中幾種常見死鎖及對策：解決死鎖沒有簡單的方法，這是因為線程產生死鎖都各有各的原因，而且往往具有很高的負載。大多數軟體測試產生不了足夠多的負載，所以不可能暴露所有的線程錯誤。在這里中，下面將討論開發過程常見的4類典型的死鎖和解決對策。(1)資料庫死鎖在資料庫中，如果一個連接佔用了另一個連接所需的資料庫鎖，則它可以阻塞另一個連接。如果兩個或兩個以上的連接相互阻塞，則它們都不能繼續執行，這種情況稱為資料庫死鎖。資料庫死鎖問題不易處理，通常數據行進行更新時，需要鎖定該數據行，執行更新，然後在提交或回滾封閉事務時釋放鎖。由於資料庫平台、配置的隔離級以及查詢提示的不同，獲取的鎖可能是細粒度或粗粒度的，它會阻塞（或不阻塞）其他對同一數據行、表或資料庫的查詢。基於資料庫模式，讀寫操作會要求遍歷或更新多個索引、驗證約束、執行觸發器等。每個要求都會引入鎖。此外，其他應用程序還可能正在訪問同一資料庫模式中的某些對象，並獲取不同應用程序所具有的鎖。所有這些因素綜合在一起，資料庫死鎖幾乎不可能被消除了。值得慶幸的是，資料庫死鎖通常是可恢復的：當資料庫發現死鎖時，它會強制銷毀一個連接（通常是使用最少的連接），並回滾其事務。這將釋放所有與已經結束的事務相關聯的鎖，至少允許其他連接中有一個可以獲取它們正在被阻塞的鎖。由於資料庫具有這種典型的死鎖處理行為，所以當出現資料庫死鎖問題時，資料庫常常只能重試整個事務。當資料庫連接被銷毀時，會拋出可被應用程序捕獲的異常，並標識為資料庫死鎖。如果允許死鎖異常傳播到初始化該事務的代碼層之外，則該代碼層可以啟動一個新事務並重做先前所有工作。當出現問題就重試，由於資料庫可以自由地獲取鎖，所以幾乎不可能保證兩個或兩個以上的線程不發生資料庫死鎖。此方法至少能保證在出現某些資料庫死鎖情況時，應用程序能正常運行。(2)資源池耗盡死鎖客戶端的增加導致資源池耗盡死鎖是由於負載而造成的，即資源池太小，而每個線程需要的資源超過了池中的可用資源。假設連接池最多有10個連接，同時有10個對外部並發調用。這些線程中每一個都需要一個資料庫連接用來清空池。現在，每個線程都執行嵌套的調用。則所有線程都不能繼續，但又都不放棄自己的第一個資料庫連接。這樣，10個線程都將被死鎖。研究此類死鎖，會發現線程存儲中有大量等待獲取資源的線程，以及同等數量的空閑且未阻塞的活動資料庫連接。當應用程序死鎖時，如果可以在運行時檢測連接池，就能確認連接池實際上已空。修復此類死鎖的方法包括：增加連接池的大小或者重構代碼，以便單個線程不需要同時使用很多資料庫連接。或者可以設置內部調用使用不同的連接池，即使外部調用的連接池為空，內部調用也能使用自己的連接池繼續。(3)單線程、多沖突資料庫連接死鎖對同一線程執行嵌套的調用有時出現死鎖，此情形即使在非高負載系統中通常也會發生。當第一個（外部）連接已獲取第二個（內部）連接所需要的資料庫鎖，則第二個連接將永久阻塞第一個連接，並等待第一個連接被提交或回滾，這就出現了死鎖情形。因為資料庫沒有注意到兩個連接之間的關系，所以資料庫不會將此情形檢測為死鎖。這樣即使不存在並發，此代碼也將導致死鎖。此情形有多種具體的變種，可以涉及多個線程和兩個以上的資料庫連接。(4)Java虛擬機鎖與資料庫鎖沖突這種情形發生在資料庫鎖與Java虛擬機鎖並存的時候。在這種情況下，一個線程佔有一個資料庫鎖並嘗試獲取Java虛擬機鎖。同時，另一個線程佔有Java虛擬機鎖並嘗試獲取資料庫鎖。此時，資料庫發現一個連接阻塞了另一個連接，但由於無法阻止連接繼續，所以不會檢測到死鎖。Java虛擬機發現同步的鎖中有一個線程，並有另一個嘗試進入的線程，所以即使Java虛擬機能檢測到死鎖並對它們進行處理，它還是不會檢測到這種情況。總而言之，JAVA應用程序中的死鎖是一個大問題——它能導致整個應用程序慢慢終止，還很難被分離和修復，尤其是當開發人員不熟悉如何分析死鎖環境的時候。五.死鎖的經驗法則筆者在開發中總結以下死鎖問題的經驗。(1)對大多數的Java程序員來說最簡單的防止死鎖的方法是對競爭的資源引入序號,如果一個線程需要幾個資源,那麼它必須先得到小序號的資源,再申請大序號的資源。可以在Java代碼中增加同步關鍵字的使用，這樣可以減少死鎖，但這樣做也會影響性能。如果負載過重，資料庫內部也有可能發生死鎖。(2)了解資料庫鎖的發生行為。假定任何資料庫訪問都有可能陷入資料庫死鎖狀況，但是都能正確進行重試。例如了解如何從應用伺服器獲取完整的線程轉儲以及從資料庫獲取資料庫連接列表（包括互相阻塞的連接），知道每個資料庫連接與哪個Java線程相關聯。了解Java線程和資料庫連接之間映射的最簡單方法是向連接池訪問模式添加日誌記錄功能。(3)當進行嵌套的調用時，了解哪些調用使用了與其它調用同樣的資料庫連接。即使嵌套調用運行在同一個全局事務中，它仍將使用不同的資料庫連接，而不會導致嵌套死鎖。(4)確保在峰值並發時有足夠大的資源池。(5)避免執行資料庫調用或在佔有Java虛擬機鎖時，執行其他與Java虛擬機無關的操作。最重要的是，多線程設計雖然是困難的，但在開始編程之前詳細設計系統能夠幫助你避免難以發現死鎖的問題。死鎖在語言層面上不能解決，就需要一個良好設計來避免死鎖。
❸ 軟體(死鎖)
產生死鎖的原因主要是：
（1） 因為系統資源不足。
（2） 進程運行推進的順序不合適。
（3） 資源分配不當等。
程序死鎖的解決辦法：
（1）合理安排表訪問順序。
（2）在事務中盡量避免用戶干預，盡量使一個事務處理的任務少些, 保持事務簡短並在一個批處理中。
（3）數據訪問時域離散法, 數據訪問時域離散法是指在客戶機/伺服器結構中，採取各種控制手段控制對資料庫或資料庫中的對象訪問時間段。主要通過以下方式實現: 合理安排後台事務的執行時間，採用工作流對後台事務進行統一管理。工作流在管理任務時，一方面限制同一類任務的線程數（往往限制為1個），防止資源過多佔用; 另一方面合理安排不同任務執行時序、時間，盡量避免多個後台任務同時執行，另外， 避免在前台交易高峰時間運行後台任務。
（4）數據存儲空間離散法。數據存儲空間離散法是指採取各種手段，將邏輯上在一個表中的數據分散到若干離散的空間上去，以便改善對表的訪問性能。主要通過以下方法實現: 第一，將大表按行或列分解為若干小表; 第二，按不同的用戶群分解。
（5）使用盡可能低的隔離性級別。隔離性級別是指為保證資料庫數據的完整性和一致性而使多用戶事務隔離的程度，SQL92定義了4種隔離性級別：未提交讀、提交讀、可重復讀和可串列。如果選擇過高的隔離性級別，如可串列，雖然系統可以因實現更好隔離性而更大程度上保證數據的完整性和一致性，但各事務間沖突而死鎖的機會大大增加，大大影響了系統性能。
（6）使用綁定連接, 綁定連接允許兩個或多個事務連接共享事務和鎖，而且任何一個事務連接要申請鎖如同另外一個事務要申請鎖一樣，因此可以允許這些事務共享數據而不會有加鎖的沖突。
作為一個系統設計員，我想是不會考慮用單一的辦法解決死鎖問題，應該具體問題具體分析。