本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 疑難排解常見問答集
<a name="troubleshooting-faqs"></a>

當您 適用於 Kotlin 的 AWS SDK 在應用程式中使用 時，您可能會遇到本主題中列出的一些問題。使用下列建議來協助找出根本原因並解決錯誤。

## 如何修正「連線已關閉」問題？
<a name="ts-faq-connection-closed"></a>

您可能會遇到「連線關閉」問題，例如下列其中一種類型的例外狀況：
+ `IOException: unexpected end of stream on {{<URL>}}`
+ `EOFException: \n not found: limit=0`
+ `HttpException: AWS_ERROR_HTTP_CONNECTION_CLOSED: The connection has closed or is closing.; crtErrorCode=2058; HttpErrorCode(CONNECTION_CLOSED)`

這些例外狀況表示從 SDK 到服務的 TCP 連線意外關閉或重設。您的主機、 AWS 服務或 NAT 閘道、代理或負載平衡器等中介方可能已關閉連線。

這些類型的例外狀況會自動重試，但仍然會出現在 SDK 日誌中，視您的記錄組態而定。如果將例外狀況擲入您的程式碼中，表示作用中的重試策略已耗盡其設定的限制，例如最大嘗試次數或重試權杖儲存貯體。如需重試策略的詳細資訊，請參閱本指南的 [中的重試次數適用於 Kotlin 的 AWS SDK](retries.md)一節。另請參閱[為什麼在達到嘗試次數上限之前擲回例外狀況？](#ts-faq-exceptions-before-max)。

### 使用 OkHttpEngine 進行閒置連線監控
<a name="ts-faq-connection-closed-okhttp"></a>

如果您使用 `OkHttpEngine`並經常遇到`IOException: unexpected end of stream on <URL>`例外狀況，[請考慮啟用閒置連線監控](http-client-config.md#http-idle-connection-monitoring)。此功能會偵測遠端伺服器何時具有仍在連線集區中的封閉連線，這可以減少這些例外狀況的發生。

## 為什麼在達到嘗試次數上限之前擲回例外狀況？
<a name="ts-faq-exceptions-before-max"></a>

有時您可能會看到預期會重試的例外狀況，但會改為擲回。在這些情況下，下列步驟可能有助於解決問題。
+ **確認例外狀況可重試。**有些例外狀況無法重試，例如表示服務請求格式不正確、缺少許可和不存在的資源等。開發套件不會自動重試這類例外狀況。如需如何檢查可重試例外狀況的資訊，請參閱 [檢查例外狀況是否可重試](retries.md#retries-check-exception-retryable)。
+ **確認例外狀況已擲入您的程式碼中。**有些例外狀況會在日誌訊息中顯示為資訊，但實際上不會擲入您的程式碼中。例如，由於 SDK 會自動執行多個backoff-and-retry週期，因此可能會記錄可重試的例外狀況，例如調節錯誤。只有在設定的重試設定未處理 SDK 操作時，才會擲回例外狀況。
+ **驗證您設定的重試設定。**如需重試策略和重試政策的詳細資訊，請參閱本指南的 [中的重試次數適用於 Kotlin 的 AWS SDK](retries.md)一節。確保您的程式碼使用您預期的設定或自動預設值。
+ **請考慮調整您的重試設定。**驗證先前項目但問題未解決後，您可以考慮調整重試設定。
  + **增加最大嘗試次數。**根據預設， 操作的嘗試次數上限為 3 次。如果您發現這不夠，且預設設定仍然發生例外狀況，請考慮在用戶端組態中增加 `retryStrategy.maxAttempts` 屬性。如需詳細資訊，請參閱[設定最大嘗試次數](retries.md#retires-max-attempts)。
  + **增加延遲設定。**在基礎條件有機會解決之前，某些例外狀況可能會嘗試過快。如果您懷疑確實如此，請考慮增加用戶端組態中的 `retryStrategy.delayProvider.initialDelay`或 `retryStrategy.delayProvider.maxBackoff` 屬性。如需詳細資訊，請參閱[設定延遲和退避](retries.md#retries-delays-backoff)。
  + **停用斷路器模式。**軟體開發套件預設會維護每個服務用戶端的字符儲存貯體。當 SDK 嘗試請求，但失敗並出現可重試的例外狀況時，字符計數會減少；當請求成功時，字符計數會遞增。

    根據預設，如果此字符儲存貯體達到剩餘 0 個字符，則電路會中斷。電路中斷後，開發套件會停用重試，且任何在第一次嘗試時失敗的目前和後續請求都會立即擲回例外狀況。開發套件會在初次嘗試成功傳回足夠的容量給字符儲存貯體後重新啟用重試。此行為是刻意的，旨在防止在服務中斷和服務復原期間重試風暴。

    如果您希望軟體開發套件繼續重試直到設定的嘗試次數上限，請考慮在用戶端組態中將 `retryStrategy.tokenBucket.useCircuitBreakerMode` 屬性設定為 false，以停用斷路器模式。將此屬性設定為 false 時，SDK 用戶端會等到字符儲存貯體達到足夠的容量，而不是放棄進一步的重試，這可能會在剩餘 0 個字符時導致例外狀況。

## 如何修正 `NoSuchMethodError`或 NoClassDefFoundError？
<a name="ts-faq-nusuchmethod"></a>

這些錯誤最常見的原因是相依性遺失或衝突。如需詳細資訊，請參閱[如何解決相依性衝突？](ts-faq-dep-conflict-resolution.md)。

### 我看到適用於 `NoClassDefFoundError`的 `okhttp3/coroutines/ExecuteAsyncKt`
<a name="ts-faq-nusuchmethod-okhttp"></a>

這表示 OkHttp 的相依性問題。如需詳細資訊，請參閱[解決應用程式中的 OkHttp 版本衝突](ts-faq-dep-conflict-resolution.md#okhttp-dep-conflicts)。