千年殇,遮天辰东小说笔趣阁

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

Java中HttpURLConnection 與 PoLA 法則

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

成都創(chuàng)新互聯(lián)是一家專業(yè)提供正鑲白企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、成都網(wǎng)站建設(shè)、HTML5、小程序制作等業(yè)務(wù)。10年已為正鑲白眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站建設(shè)公司優(yōu)惠進(jìn)行中。

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

無論如何，先說點(diǎn)背景情況吧，我們的項(xiàng)目里有自動(dòng)記錄活動(dòng)日志的功能，當(dāng)某些情況下，比如一個(gè)進(jìn)程啟動(dòng)的時(shí)候就會進(jìn)行記錄。這包括我們那出問題的網(wǎng) 絡(luò)服務(wù)客戶端和服務(wù)端，因?yàn)樗鼈儍烧叨紝儆谙到y(tǒng)的一部分。在某些時(shí)候，我們注意到，服務(wù)端的響應(yīng)還沒有發(fā)出的時(shí)候，另外一個(gè)來自同樣客戶端的請求又發(fā)了過來。這個(gè)真是出乎意料的，因?yàn)榭蛻舳舜a是單線程的，也沒有其他的客戶端摻和進(jìn)來。審查代碼、測試之后，結(jié)論是我們的客戶端不可能在第一個(gè)請求還沒結(jié)束的時(shí)候再同時(shí)發(fā)出另外一個(gè)。

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

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

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

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

運(yùn)行之，將會得到類似下面的輸出。

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)聽服務(wù)被調(diào)用了兩次，但是我們只發(fā)了一個(gè)請求。如果我們加上-Dsun.net.http.retryPost=false這個(gè)屬性再運(yùn)行一次的話，我們會得到下面的輸出：

------> 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)
 ...

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

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

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

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

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

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

網(wǎng)站題目：Java中HttpURLConnection 與 PoLA 法則
地址分享：http://m.fisionsoft.com.cn/article/cceescs.html

新聞中心

其他資訊