本文是公司内一个问题的分析记录。涉及的框架为apache的commons-httpclient 3.x。 问题特征 无法从连接池中获取连接，异常描述为timeout waiting for connection netstat看到连接状态为CLOSE_WAIT 目标服务器ping得通，甚至curl等方式亦可以获取结果

其实这不是什么神奇的trick，只是很多人包括我在一直以来使用Java的日志框架比如log4j时没有意识到可以动态改变日志级别。如果你看到别人这么写了的话，很快就会转变观念的，我也是。 https://github.com/xnnyygn/dynamic-log-level 这个github是我整理的log4j动态改变日志级别的代码以及测试，有兴趣的可以参考下。 个人觉得这个trick可以用的地方还是程序员给自己开“后门”，特别是查线上问题时。由于很多人打印日志的级别的convention不一致。比如我喜欢非常详细的输入参数和输出结果用DEBUG，但是有些人就喜欢打INFO。一些复杂的逻辑有些人打了十几八行的INFO级别日志，看得我心烦，这帮人打INFO就像喝水一样……所以有些时候临时改变日志级别可能是有用的。不过从开发上来说，没有很好地统一日志级别规范，没有重视CR，是导致这个问题的主因，但是作为程序员要给自己留一手，比如动态改变日志级别之类的。

本篇文章本来打算在上个月下半旬写的，不过个人状态一直都不太好，最近重新开始调整自己的技术心态，慢慢恢复，这篇也算是恢复中的一小步吧。 延迟初始化是我在上个月公司的一个项目中加入的一个技术，感觉小组对这种东西不感兴趣，所以还是放到自己的博客上来了。技术背景是业务对象是一个非常大的对象（胖领域模型），每次加载非常耗时，而且因为部分非关键服务的不稳定导致不需要这些服务数据的功能不可用。举个例子，导航页不需要用户的B信息，但是每次加载用户信息由于是在服务层（是的，传统的分层结构）加载的，无法直接控制加载的内容，所以导致在B服务失败之后，导航页不可用。 从技术角度来说，领域模型完全是保证业务执行的必要条件，但是实际情况并不是所有场景都需要这么严格的领域模型完整性的保证的，所以类似“降级”的处理方式应由而生。具体来说就是“按需加载”。实现“按需加载”的方式不仅仅只有延迟初始化一种，通过服务的参数显示地控制加载的内容也是一种方式，不过存在侵入性和严格的规约，对开发来说并不是那么方便。其实“按需加载”不是只在特定业务场景才有的需求，在ORM上，加载关联数据也是一种典型的“按需加载”。所以亦可以参考ORM在“按需加载”方面的实现。 在讲我的简化版延迟初始化之前，先大致讲下Hibernate这个ORM在按需加载上的处理。Hibernate主要支持one-to-one和one-to-many下的按需加载，Hibernate 3开始支持部分字段的按需加载（CLOB和BLOB不算在内，3之前就有支持）。实现上，部分字段的加载需要bytecode替换，one-to-many是通过改写集合的处理，one-to-one是通过代理对象，具体来说是CGLIB，因为JDK动态代理对象只支持接口。 了解这些对于我的实现有所帮助，不过除了one-to-many很快就能模仿写之外，部分字段的延迟初始化和one-to-one的处理都比较麻烦。one-to-one在查到结果为null时会比较麻烦，从调用上看应该是代理整个领域模型而不是单个延迟加载的对象，这块个人没有细究，因为我后来想想我不需要非常严格的模型字段规约，小小地修改模型理论上也不会有太大问题。而且部分字段的延迟初始化不是类似单个延迟初始化对象就可以解决的。