當試圖執行由於某些資源的臨時或永久限制而可能失敗的任務時,我傾向於使用退避策略。這種策略已經被用於消息隊列和套接字打開等各種各樣的事情。
這種策略的一般過程如下。
set maxdelay to 16 # maximum time period between attempts
set maxtries to 10 # maximum attempts
set delay to 0
set tries to 0
while more actions needed:
if delay is not 0:
sleep delay
attempt action
if action failed:
add 1 to tries
if tries is greater than maxtries:
exit with permanent error
if delay is 0:
set delay to 1
else:
double delay
if delay is greater than maxdelay:
set delay to maxdelay
else:
set delay to 0
set tries to 0
這使得處理能夠以全速在絕大多數情況下運行,但回退時的錯誤開始發生,希望給資源提供者的時間來恢復。延遲的逐漸增加允許更嚴重的資源限制來恢復,並且最大的嘗試可以捕捉到您所稱的永久性錯誤(或需要很長時間才能恢復的錯誤)。
我其實更喜歡try-it-and-catch-failure方法來檢查if-okay-then-try之一,因爲如果檢查和try之間有變化,後者通常可能會失敗。這就是所謂的「更好地尋求寬恕比要求許可」方法,這也工作得很好與老闆們的大部分時間,和妻子經常少一些:-)
一個特別有用的情況下是一個程序,爲每個短期交易打開一個單獨的TCP會話。在較舊的硬件上,關閉的套接字(處於TCP WAIT狀態的套接字)最終在再次需要之前消失。
但是,隨着硬件速度的加快,我們發現我們可以打開會話並更快地開展工作,並且Windows耗盡TCP處理(即使增加到最大)。
該策略的實施並不需要重新設計通信協議來維護會話,而是在事件句柄被餓死時進行優雅恢復。
表面上看起來有點混亂,但這是傳統軟件即將報廢,錯誤修復通常足以讓它工作,並且它不被認爲具有足夠的戰略性以保證花費大量資金正確安裝。
更新:這可能是因爲有一個(更持久的)問題PresentationCore。這個KB article指出.NET 3.5SP1(其打印驅動程序可能是客戶端)中的WPF中存在內存泄漏。
如果退避策略不能解決您的問題(也可能沒有,如果它在一個長壽命過程中的泄漏),你可能會想嘗試應用修補程序。我,我會在虛擬機中複製這個問題,然後修補它來測試它(但我是一個極端的偏執狂)。
通過Google搜索PresentationCore Insufficient memory to continue the execution of the program
並檢查第一個鏈接here發現。搜索該頁面上的字符串「與此問題相關的修補程序」。