如果你和我一樣也是開發(fā)者的話，你很可能已經(jīng)聽說過“PoLA”原則，或者叫作“產(chǎn)生最少意外”原則。意思非常簡單，就是不要讓你的用戶感到驚訝。 或者更明確一些，就像本文這種情況，不要讓另外一個開發(fā)者感到驚訝。不幸的是，我上個星期就遇到了大大超出我意外的事情，我們有個服務的客戶調(diào)用端總是發(fā) 出一些垃圾的請求。

你說垃圾請求嗎？是的，就像這樣，我們完全不清楚這些請求是從哪里來的。又是這樣一個時刻，經(jīng)理們毫無頭緒，抱頭亂竄，驚呼“我們肯定是被黑客攻擊了”，或者 ”有人把防火墻給關(guān)掉了?。?rdquo;

無論如何，先說點背景情況吧，我們的項目里有自動記錄活動日志的功能，當某些情況下，比如一個進程啟動的時候就會進行記錄。這包括我們那出問題的網(wǎng) 絡服務客戶端和服務端，因為它們兩者都屬于系統(tǒng)的一部分。在某些時候，我們注意到，服務端的響應還沒有發(fā)出的時候，另外一個來自同樣客戶端的請求又發(fā)了過 來。這個真是出乎意料的，因為客戶端代碼是單線程的，也沒有其他的客戶端摻和進來。審查代碼、測試之后，結(jié)論是我們的客戶端不可能在第一個請求還沒結(jié)束的 時候再同時發(fā)出另外一個。

經(jīng)過一整天的調(diào)試和研究日志發(fā)現(xiàn)，事實上，在服務端處理還未結(jié)束的時候客戶端其實已經(jīng)斷開連接了。所以，這些請求終究并不是同時發(fā)生的，但是為什么我們花了一整天的時間才發(fā)現(xiàn)呢？這跟我們玩了一整天的星球大戰(zhàn)有啥區(qū)別？

好吧，其實也不是。我們發(fā)現(xiàn)了罪魁禍首，服務端的容器軟件HTTP的讀超時設置被調(diào)得太低了。服務端的日志顯示的確生成了響應，但是客戶端卻在此之 前已經(jīng)斷開了，因為服務器端發(fā)生了讀超時。這些在服務器端當然沒有日志記錄，因為這種行為是更低一層協(xié)議決定的（HTTP棧），而不是服務端的應用代碼。

是的，沒錯，我聽明白了，但是客戶端的日志該怎么解釋？客戶端是不是應該拋出一個“ReadTimeoutException”異常，或者類似的玩 意，然后可以寫到日志里？然而，沒錯，事實上，并沒有。就像現(xiàn)在發(fā)現(xiàn)的一樣，真正的意外來自HttpURLConnection類的內(nèi)部（更確切地說，是 默認的Oracle的官方實現(xiàn)sun.net.www.protocol.http.HttpURLConnection）。

你以前是否知道HttpURLConnection的默認實現(xiàn)有個在某些情形下自動重試的特性？好吧，我之前就不知道。當時的情況是，客戶端的確觸 發(fā)了超時異常，但是卻被HttpURLConnection給捕捉了，而它自己決定重新嘗試一次。這就意味著，你調(diào)用了 HttpURLConnection的read()方法，它阻塞了，你正在等待，看起來就好像是在等待第一次請求的響應一樣。但是在 HttpURLConnection內(nèi)部，它作了不止一次嘗試，因此創(chuàng)建了不止一個socket連接。這就解釋了為什么第二次及以后的請求永遠在日志里找 不到，因為這些第二次之后的請求是HttpURLConnection內(nèi)部發(fā)起的。

讓我們上一些代碼重現(xiàn)一下。

import java.net.HttpURLConnection;
import java.net.InetSocketAddress;
import java.net.SocketTimeoutException;
import java.net.URL;
import java.util.concurrent.Executors;
import com.sun.net.httpserver.HttpServer;
/**
 * Created by koen on 30/01/16.
 */
public class TestMe {
 public static void main(String[] args) throws Exception {
  startHttpd();
  HttpURLConnection httpURLConnection = (HttpURLConnection) new URL("http://localhost:8080/").openConnection();
  if (!(httpURLConnection instanceof sun.net.www.protocol.http.HttpURLConnection)) {
   throw new IllegalStateException("Well it should really be sun.net.www.protocol.http.HttpURLConnection. "
     + "Check if no library registered it's impl using URL.setURLStreamHandlerFactory()");
  }
  httpURLConnection.setRequestMethod("POST");
  httpURLConnection.connect();
  System.out.println("Reading from stream...");
  httpURLConnection.getInputStream().read();
  System.out.println("Done");
 }
 public static void startHttpd() throws Exception {
  InetSocketAddress addr = new InetSocketAddress(8080);
  HttpServer server = HttpServer.create(addr, 0);
  server.createContext("/", httpExchange -> {
   System.out.println("------> Httpd got request. Request method was:" + httpExchange.getRequestMethod() + " Throwing timeout exception");
   if (true) {
    throw new SocketTimeoutException();
   }
  });
  server.setExecutor(Executors.newCachedThreadPool());
  server.start();
  System.out.println("Open for business.");
 }
}

運行之，將會得到類似下面的輸出。

Open for business.
Reading from stream...
------> Httpd got request. Request method was:POST Throwing timeout exception
------> Httpd got request. Request method was:POST Throwing timeout exception
Exception in thread "main" java.net.SocketException: Unexpected end of file from server
 at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:792)
 ...

注意，我們的監(jiān)聽服務被調(diào)用了兩次，但是我們只發(fā)了一個請求。如果我們加上-Dsun.net.http.retryPost=false這個屬性再運行一次的話，我們會得到下面的輸出：

------> Httpd got request. Request method was:POST Throwing timeout exception
Exception in thread "main" java.net.SocketException: Unexpected end of file from server
 at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:792)
 ...

好，先把這事放一邊，我想問的是，到底是誰搞出這么個設計來，既沒文檔描述又沒有可配置選項？為啥我做了十五年的Java開發(fā)，卻對此一無所知？更要命的是，為什么它要對一個構(gòu)造異常的POST請求進行重試呢？這是對PoLA赤裸裸的違背！

現(xiàn)在你可能已經(jīng)猜到了，這是一個BUG（鏈接：http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6382788）。 當然了，說是BUG并不是指的它的重試機制，而是指它為什么對異常POST請求也會進行重試。按照HTTP RFC的規(guī)范，POST請求并非冪等，因此多次提交POST會帶來服務器端數(shù)據(jù)的改變。但是別擔心，Bill早就把這個BUG修改好了。Bill的解決方 法是加了一個開關(guān)。Bill了解向后兼容原則。Bill認為最好的方法是添加一個默認開啟的開關(guān)，這樣可以保證這個BUG的向后兼容。Bill笑了。 Bill已經(jīng)能夠看見全球無數(shù)的Java開發(fā)者掉進這個大坑時驚愕的面孔。但是，你們都別學Bill好嗎？

經(jīng)過好幾天激動人心的調(diào)試，最后問題解決的方式卻略顯輕巧，僅僅指定了一個屬性就搞定了。無論如何，這個設計真是著實讓我很意外，因此我還專門寫了這篇文章來講述，并且，你也看到了這篇文章。

為了完整起見，再提醒一下，如果你讓這段代碼在容器環(huán)境里執(zhí)行的話，結(jié)果可能會不同。你的容器或者你的代碼所依賴的庫有可能會替換掉Oracle默 認的內(nèi)部實現(xiàn)，請參考URL.setURLStreamHandlerFactory()?，F(xiàn)在你可能會問，那個家伙當時為什么要使用 HttpURLConnection呢？他難道是坐著演講巡游車上班嗎（原文Wooden Soapbox,由來參見https://en.wikipedia.org/wiki/Soapbox）？他難道是用剪子來割草嗎？建議他傳遞信息的時 候最好還是使用烽火吧！當然了，你這么想我也不能責怪你。我們出問題的代碼有點特別，使用的是SAAJ中的SOAPConnectionFactory， 而SOAPConnectionFactory內(nèi)部又默認使用了HttpURLConnection，如果沒有其他代碼來注冊其他的實現(xiàn)類的話，使用的當 然就是默認的Oracle實現(xiàn)嘍~

如果你使用其他更專業(yè)的web服務實現(xiàn)的時候（如Spring WS, CXF, JAX-WS實現(xiàn)等等），他們很可能使用了諸如Apache HTTP Client的組件。當然了，如果你自己的代碼需要發(fā)起HTTP連接的話，你也可以使用它。沒錯，我還是推薦你使用Apache Commons HttpClient,雖然這貨修改API的頻率比普通時尚達人換鞋的頻率都還要高。好了，我的牢騷完了。

譯文鏈接：http://www.codeceo.com/article/java-httpurlconnection-pola.html
英文原文：HttpURLConnection vs. the Principle of Least Astonishment