java 中 httpurlconnection 与 pola 法则-亚博电竞手机版

本文由码农网 – sandbox wang原创翻译，转载请看清文末的转载要求，欢迎参与我们的付费投稿计划！

引言：如果你也是开发者的话，你很可能已经知道pola法则（principle of lease astonishment）。那么，看看这篇文章讲述的充满奇幻色彩的调试经历，来见识一下pola是如何与httpurlconnection发生了关联。

如果你和我一样也是开发者的话，你很可能已经听说过“pola”原则，或者叫作“产生最少意外”原则。意思非常简单，就是不要让你的用户感到惊讶。或者更明确一些，就像本文这种情况，不要让另外一个开发者感到惊讶。不幸的是，我上个星期就遇到了大大超出我意外的事情，我们有个服务的客户调用端总是发出一些垃圾的请求。

你说垃圾请求吗？是的，就像这样，我们完全不清楚这些请求是从哪里来的。又是这样一个时刻，经理们毫无头绪，抱头乱窜，惊呼“我们肯定是被黑客攻击了”，或者 ”有人把防火墙给关掉了！！”

无论如何，先说点背景情况吧，我们的项目里有自动记录活动日志的功能，当某些情况下，比如一个进程启动的时候就会进行记录。这包括我们那出问题的网络服务客户端和服务端，因为它们两者都属于系统的一部分。在某些时候，我们注意到，服务端的响应还没有发出的时候，另外一个来自同样客户端的请求又发了过来。这个真是出乎意料的，因为客户端代码是单线程的，也没有其他的客户端掺和进来。审查代码、测试之后，结论是我们的客户端不可能在第一个请求还没结束的时候再同时发出另外一个。

经过一整天的调试和研究日志发现，事实上，在服务端处理还未结束的时候客户端其实已经断开连接了。所以，这些请求终究并不是同时发生的，但是为什么我们花了一整天的时间才发现呢？这跟我们玩了一整天的星球大战有啥区别？

好吧，其实也不是。我们发现了罪魁祸首，服务端的容器软件http的读超时设置被调得太低了。服务端的日志显示的确生成了响应，但是客户端却在此之前已经断开了，因为服务器端发生了读超时。这些在服务器端当然没有日志记录，因为这种行为是更低一层协议决定的（http栈），而不是服务端的应用代码。

是的，没错，我听明白了，但是客户端的日志该怎么解释？客户端是不是应该抛出一个“readtimeoutexception”异常，或者类似的玩意，然后可以写到日志里？然而，没错，事实上，并没有。就像现在发现的一样，真正的意外来自httpurlconnection类的内部（更确切地说，是默认的oracle的官方实现sun.net.www.protocol.http.httpurlconnection）。

你以前是否知道httpurlconnection的默认实现有个在某些情形下自动重试的特性？好吧，我之前就不知道。当时的情况是，客户端的确触发了超时异常，但是却被httpurlconnection给捕捉了，而它自己决定重新尝试一次。这就意味着，你调用了httpurlconnection的read()方法，它阻塞了，你正在等待，看起来就好像是在等待第一次请求的响应一样。但是在httpurlconnection内部，它作了不止一次尝试，因此创建了不止一个socket连接。这就解释了为什么第二次及以后的请求永远在日志里找不到，因为这些第二次之后的请求是httpurlconnection内部发起的。

让我们上一些代码重现一下。

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

注意，我们的监听服务被调用了两次，但是我们只发了一个请求。如果我们加上-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开发，却对此一无所知？更要命的是，为什么它要对一个构造异常的post请求进行重试呢？这是对pola赤裸裸的违背！

现在你可能已经猜到了，这是一个bug（链接：http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6382788）。当然了，说是bug并不是指的它的重试机制，而是指它为什么对异常post请求也会进行重试。按照http rfc的规范，post请求并非幂等，因此多次提交post会带来服务器端数据的改变。但是别担心，bill早就把这个bug修改好了。bill的解决方法是加了一个开关。bill了解向后兼容原则。bill认为最好的方法是添加一个默认开启的开关，这样可以保证这个bug的向后兼容。bill笑了。bill已经能够看见全球无数的java开发者掉进这个大坑时惊愕的面孔。但是，你们都别学bill好吗？

经过好几天激动人心的调试，最后问题解决的方式却略显轻巧，仅仅指定了一个属性就搞定了。无论如何，这个设计真是着实让我很意外，因此我还专门写了这篇文章来讲述，并且，你也看到了这篇文章。

为了完整起见，再提醒一下，如果你让这段代码在容器环境里执行的话，结果可能会不同。你的容器或者你的代码所依赖的库有可能会替换掉oracle默认的内部实现，请参考url.seturlstreamhandlerfactory()。现在你可能会问，那个家伙当时为什么要使用httpurlconnection呢？他难道是坐着演讲巡游车上班吗（原文wooden soapbox,由来参见https://en.wikipedia.org/wiki/soapbox）？他难道是用剪子来割草吗？建议他传递信息的时候最好还是使用烽火吧！当然了，你这么想我也不能责怪你。我们出问题的代码有点特别，使用的是saaj中的soapconnectionfactory，而soapconnectionfactory内部又默认使用了httpurlconnection，如果没有其他代码来注册其他的实现类的话，使用的当然就是默认的oracle实现喽~

如果你使用其他更专业的web服务实现的时候（如spring ws, cxf, jax-ws实现等等），他们很可能使用了诸如apache http client的组件。当然了，如果你自己的代码需要发起http连接的话，你也可以使用它。没错，我还是推荐你使用apache commons httpclient,虽然这货修改api的频率比普通时尚达人换鞋的频率都还要高。好了，我的牢骚完了。

译文链接：http://www.codeceo.com/article/java-httpurlconnection-pola.html
英文原文：httpurlconnection vs. the principle of least astonishment
翻译作者：码农网 – sandbox wang
[ 转载必须在正文中标注并保留原文链接、译文链接和译者等信息。]