系统上线之后，通过如下语句查看服务器时，发现有不少TIME_WAIT和CLOSE_WAIT。

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

打印显示如下：

TIME_WAIT 297
ESTABLISHED 53
CLOSE_WAIT 5

     TIME_WAIT：表示主动关闭，通过优化系统内核参数可容易解决。

     CLOSE_WAIT：表示被动关闭，需要从程序本身出发。

     ESTABLISHED：表示正在通信

    通过上网了解，总结如下：

一、TIME_WAIT（通过优化系统内核参数可容易解决）

       TIME_WAIT是主动关闭连接的一方保持的状态，对于服务器来说它本身就是“客户端”，在完成一个爬取任务之后，它就会发起主动关闭连接，从而进入TIME_WAIT的状态，然后在保持这个状态2MSL（max segment lifetime）时间之后，彻底关闭回收资源。为什么要这么做？明明就已经主动关闭连接了为啥还要保持资源一段时间呢？这个是TCP/IP的设计者规定的，主要出于以下两个方面的考虑：

        1.防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）

        2.可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。

        解决方案很简单，通过修改/etc/sysctl.conf文件，服务器能够快速回收和重用那些TIME_WAIT的资源  

#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭  
net.ipv4.tcp_syncookies = 1  
#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭  
net.ipv4.tcp_tw_reuse = 1  
#表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭  
net.ipv4.tcp_tw_recycle = 1
#表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间  
net.ipv4.tcp_fin_timeout=30

        生效，如下命令        

/sbin/sysctl -p

二、CLOSE_WAIT（需要从程序本身出发）

       TCP状态转移要点

       TCP协议规定，对于已经建立的连接，网络双方要进行四次握手才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接，所以很有必要保证无用连接完全断开，否则大量僵死的连接会浪费许多服务器资源.

        客户端TCP状态迁移：        

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

       当客户端开始连接时，服务器还处于LISTENING，客户端发一个SYN包后，他就处于SYN_SENT状态,服务器就处于SYS收到状态,然后互相确认进入连接状态ESTABLISHED。

       TIME_WAIT状态可以通过优化服务器参数得到解决，因为发生TIME_WAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的。

        但是CLOSE_WAIT就不一样了，如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。个人觉得这种情况，通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行。

       什么情况下，连接处于CLOSE_WAIT状态呢？

       答案一：在被动关闭连接情况下，在已经接收到FIN，但是还没有发送自己的FIN的时刻，连接处于CLOSE_WAIT状态。通常来讲，CLOSE_WAIT状态的持续时间应该很短，正如SYN_RCVD状态。但是在一些特殊情况下，就会出现连接长时间处于CLOSE_WAIT状态的情况。

        答案二：出现大量close_wait的现象，主要原因是某种情况下对方关闭了socket链接，但是我方忙与读或者写，没有关闭连接。代码需要判断socket，一旦读到0，断开连接，read返回负，检查一下errno，如果不是AGAIN，就断开连接。

虽然lucene4很早就出来，但是这里仍然以lucene3.0为基础，理解lucene索引创建的思路：

1. 要记录正向信息

field的数据，fdx，fdt，依次写每个field的即可

词向量，tvx，tvd，tvf

tvf是真正存储的地方，tvx是每个文档一项，具体包含第一个field的位置，其他field只要记录与覅一个field的偏移量即可

2. 记录反向信息

字典信息，tii，tis，通过字典，能够找到frq位置和prx位置

即，term1记录有此文档的倒排链表的位置，以及位置信息的链表

frq是倒排表，首先是倒排表，之后是跳跃表（肯定先放正常的倒排表，有了确定的位置后，方便建跳跃表），一层一层的建。

prx文档类似的

3. 如果自己来实现，如何实现？

（1）针对正向的数据fdx，fdt，就是一个文档的每个field的进来的原始数据，因此，可以直接保存，因为这不需要额外的分析就可以确定，可以直接写到磁盘的，顺序的写。

文档1

文档2

文档3

...

文档n

（2）针对正向信息的tvx，tvd，tvf等，肯定需要等每个field的term分析结束才行，否则不可能得到完整的信息，具体一个词在本文档中的词频，位置信息，也需要分析完term才能确定

field-->term

term->docid,freq,position

（3）tii，tis，frq，prx的形成，只有在一批文档完成后，才能形成，因为只有知道了所有的文档后，按文档id排序，才能构建

tii，tis

frq->docId1，freq1；docId2，freq2

prox->docId1，prox1；docId2，prox2

4. lucene3.0中的实现

剔除掉接口的描述，只看具体的实现，其实很清楚：

        --> code: DocFieldProcessor / DocFieldProcessorPerThread

              --> code: DocInverter / DocInverterPerThread / DocInverterPerField

                  --> code: TermsHash / TermsHashPerThread / TermsHashPerField

                      --> code: FreqProxTermsWriter / FreqProxTermsWriterPerThread / FreqProxTermsWriterPerField

                      --> code: TermVectorsTermsWriter / TermVectorsTermsWriterPerThread / TermVectorsTermsWriterPerField

                  --> code: NormsWriter / NormsWriterPerThread / NormsWriterPerField

              --> code: StoredFieldsWriter / StoredFieldsWriterPerThread

处理的层次的分类规则：

（1）是所有文档共享还是线程独立

（2）是正向还是反向的处理

所有文档共享：DocFieldProcessor

所有文档的共享（正向）：StoredFieldsWriter

所有文档的共享（反向）：DocInverter

线程的入口：DocFieldProcessorPerThread

线程的处理（正向）：StoredFieldsWriterPerThread

线程的处理（反向）：DocInverterPerThread

4.1 线程的处理（正向）：StoredFieldsWriterPerThread

（1）DocumentsWriter有统一的内存管理

（2）每个线程写一个文档时，首先从池中获取一个内存块，写信息

（3）写文档结束后，直接将正向的fdt和fdx写到磁盘上，重用内存块

多个段之间的正向fdt和fdx是可以共享一个文件的。例如没有提交一批文档之前，如果内存满了，那么先flush，会生成tii，tis和frq，prx等。

之后后续commit了，会生成另一个段的tii，tis等，但是fdt和fdx是相同的。

4.2 线程的处理（反向）：DocInverterPerThread

一个文档的反向信息要缓存的信息有哪些？

（1）term的文本

（2）term对应的docId，freq，prox信息

（3）上述信息的指针

每个field的有一个缓存的term的hash数组：此hash数组的对象，包含了指针信息：term的文本的指针；term对应的prox信息（遇见一次，记录一次）

后续的文档：当遇到同样的一个term，文本重用，同样的缓存frq，prox即可。

4.3 方向信息的生成：通过flush到磁盘时，从缓存中生成。

Hibernate4的改动较大只有spring3.1以上版本能够支持，Spring3.1取消了HibernateTemplate，因为Hibernate4的事务管理已经很好了，不用Spring再扩展了。这里简单介绍了hibernate4相对于hibernate3配置时出现的错误，只列举了问题和解决方法，详细原理如果大家感兴趣还是去自己搜吧，网上很多。

1. Spring3.1去掉了HibernateDaoSupport类。hibernate4需要通过getCurrentSession()获取session。并且设置
   <prop key="hibernate.current_session_context_class">org.springframework.orm.hibernate4.SpringSessionContext</prop>
   （在hibernate3的时候是thread和jta）。

2. 缓存设置改为<prop key="hibernate.cache.provider_class">net.sf.ehcache.hibernate.EhCacheProvider</prop>
                   <prop key="hibernate.cache.region.factory_class">org.hibernate.cache.ehcache.EhCacheRegionFactory</prop>

3. Spring对hibernate的事务管理，不论是注解方式还是配置文件方式统一改为：
   <bean id="txManager" class="org.springframework.orm.hibernate4.HibernateTransactionManager" >  
   <property name="sessionFactory"><ref bean="sessionFactory"/>
   </property> 
   </bean>

4. getCurrentSession()事务会自动关闭，所以在有所jsp页面查询数据都会关闭session。要想在jsp查询数据库需要加入：
   org.springframework.orm.hibernate4.support.OpenSessionInViewFilter过滤器。

5. Hibernate分页出现 ResultSet may only be accessed in a forward direction 需要设置hibernate结果集滚动
    <prop key="jdbc.use_scrollable_resultset">false</prop>

--------------------------------------------------------------------

找到篇好文章,我之前遇到的问题都在这都能找到。其实出现这些问题的关键就是hibernate4和hibernate3出现了session管理的变动。

spring也作出相应的变动....

错误1：java.lang.NoClassDefFoundError: org/hibernate/cache/CacheProvider

原因：spring的sessionfactory和transactionmanager与支持hibernate3时不同。

解决：

<bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">

<property name="dataSource" ref="dataSource"/>

...

</bean>

<bean id="transactionManager" class="org.springframework.orm.hibernate4.HibernateTransactionManager">

<property name="sessionFactory" ref="sessionFactory"/>

</bean>

错误2：java.lang.NoSuchMethodError:org.hibernate.SessionFactory.openSession()Lorg/hibernate/classic/Session

原因：hibernate4之后，spring31把HibernateDaoSupport去除，包括数据访问都不需要hibernatetemplate，这意味着dao需要改写，直接使用hibernate的session和query接口。

解决：为了改写dao，足足花了一天时间，然后一个个接口进行单元测试，这是蛋疼的一个主要原因。

错误3：nested exception is org.hibernate.HibernateException: No Session found for current thread

原因：发现一些bean无法获得当前session，需要把之前一些方法的事务从NOT_SUPPORT提升到required,readonly=true

见https://jira.springsource.org/browse/SPR-9020， http://www.iteye.com/topic/1120924

解决：

<tx:advice id="baseServiceAdvice" transaction-manager="transactionManager">

   <tx:attributes>

      <tx:method name="get*" read-only="true" propagation="REQUIRED"/><!--之前是NOT_SUPPORT-->

      <tx:method name="find*" read-only="true" propagation="REQUIRED"/><!--之前是NOT_SUPPORT-->

      <tx:method name="save*" propagation="REQUIRED"/>

      <tx:method name="update*" propagation="REQUIRED"/>

      <tx:method name="remove*" propagation="REQUIRED"/>

      <tx:method name="add*" propagation="REQUIRED"/>

      <!--默认其他方法都是REQUIRED-->

      <tx:method name="*"/>

   </tx:attributes>

</tx:advice>

错误4:与错误3报错类似，java.lang.NoSuchMethodError:org.hibernate.SessionFactory.openSession()Lorg/hibernate/classic/Session;

        at org.springframework.orm.hibernate3.SessionFactoryUtils.doGetSession(SessionFactoryUtils.java:324) [spring-orm-3.1.1.RELEASE.jar:3.1.1.RELEASE]

        at org.springframework.orm.hibernate3.SessionFactoryUtils.getSession(SessionFactoryUtils.java:202) [spring-orm-3.1.1.RELEASE.jar:3.1.1.RELEASE]

        at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter

原因：因为opensessioninview filter的问题，如果你的配置还是hibernate3，需要改为hibernate4 

<filter>

    <filter-name>openSessionInViewFilter</filter-name>

   <filter-class>org.springframework.orm.hibernate4.support.OpenSessionInViewFilter</filter-class>

</filter>

--------------------------------------------------------------------

由于Hibernate4已经完全可以实现事务了， 与Spring3.1中的hibernatedao,hibernateTemplete等有冲突，所以Spring3.1里已经不提供Hibernatedaosupport,HibernateTemplete了，只能用Hibernate原始的方式用session:

        Session session = sessionFactory.openSession();
        Session session = sessionFactory.getCurrentSession();
在basedao里可以用注入的sessionFactory获取session.

注意, 配置事务的时候必须将父类baseServiceImpl也配上，要不然会出现错误：No Session found for currentthread, 以前是不需要的

SessionFactory.getCurrentSession()的后台实现是可拔插的。因此，引入了新的扩展接口 ( org.hibernate.context.spi.CurrentSessionContext)和

新的配置参数(hibernate.current_session_context_class)，以便对什么是“当前session”的范围和上下文(scope and context)的定义进行拔插。

在 Spring @Transactional声明式事务管理,”currentSession”的定义为: 当前被 Spring事务管理器 管理的Session,此时应配置:

hibernate.current_session_context_class= org.springframework.orm.hibernate4.SpringSessionContext。

此处一定注意 使用 hibernate4，在不使用OpenSessionInView模式时，在使用getCurrentSession()时会有如下问题： 当有一个方法list 传播行为为Supports，当在另一个方法getPage()（无事务）调用list方法时会抛出org.hibernate.HibernateException: No Session found for current thread 异常。 这是因为getCurrentSession()在没有session的情况下不会自动创建一个，不知道这是不是Spring3.1实现的bug。 因此最好的解决方案是使用REQUIRED的传播行为 。

几乎每一个前端程序员都知道应该把script标签放在页面底部。关于这个经典的论述可以追溯到Nicholas的 High Performance Javasript 这本书的第一章Loading and Execution中，他之所以建议这么做是因为：

Put all <script> tags at the bottom of the page, just inside of the closing </body> tag. This ensures that the page can be almost completely rendered before script execution begins.

简而言之，如果浏览器加载并执行脚本，会引起页面的渲染被暂停，甚至还会阻塞其他资源(比如图片)的加载。为了更快的给用户呈现网页内容，更好的用户体验，应该把脚本放在页面底部，使之最后加载。

为什么要在标题中使用“再”这个字？因为在工作中逐渐发现，我们经常谈论的一些页面优化技巧，比如上面所说的总是把脚本放在页面的底部，压缩合并样式或者脚本文件等，时至今日已不再是最佳的解决方案，甚至事与愿违，转化为性能的毒药。这篇文章所要聊的，便是展示某些不被人关注的浏览器特性或者技巧，来继续完成资源加载性能优化的任务。

一. Preloader

什么是Preloader

首先让我们看一看这样一类资源分布的 页面：

<head><link rel="stylesheet" type="text/css" href=""><script type="text/javascript"></script></head><body><img src=""><img src=""><img src=""><img src=""><img src=""><img src=""><img src=""><img src=""><script type="text/javascript"></script><script type="text/javascript"></script><script type="text/javascript"></script></body>

 这类页面的特点是，一个外链脚本置于页面头部，三个外链脚本置于页面的底部，并且是故意跟随在一系列img之后，在Chrome中页面加载的网络请求瀑布图如下：

值得注意的是，虽然脚本放置在图片之后，但加载仍先于图片。为什么会出现这样的情况？为什么故意置后资源能够提前得到加载？

虽然浏览器引擎的实现不同，但原理都十分的近似。不同浏览器的制造厂商们(vendor)非常清楚浏览器的瓶颈在哪(比如network, javascript evaluate, reflow, repaint)。针对这些问题，浏览器也在不断的进化，所以我们才能看到更快的脚本引擎，调用GPU的渲染等一推陈出新的优化技术和方案。

同样在资源加载上，早在IE8开始，一种叫做lookahead pre-parser(在Chrome中称为preloader)的机制就已经开始在不同浏览器中兴起。IE8相对于之前IE版本的提升除了将每台host最高并行下载的资源数从2提升至6，并且能够允许并行下载脚本文件之外，最后就是这个lookahead pre-parser机制

但我还是没有详述这是一个什么样的机制，不着急，首先看看与IE7的对比：

以上面的页面为例，我们看看IE7下的瀑布图：

底部的脚本并没有提前被加载，并且因为由于单个域名最高并行下载数2的限制，资源总是两个两个很整齐的错开并行下载。

但在IE8下，很明显底部脚本又被提前：

并没有统一的标准规定这套机制应具备何种功能已经如何实现。但你可以大致这么理解：浏览器通常会准备两个页面解析器parser，一个(main parser)用于正常的页面解析，而另一个(preloader)则试图去文档中搜寻更多需要加载的资源，但这里的资源通常仅限于外链的js、stylesheet、image；不包括audio、video等。并且动态插入页面的资源无效。

但细节方面却值得注意：

1. 比如关于preloader的触发时机，并非与解析页面同时开始，而通常是在加载某个head中的外链脚本阻塞了main parser的情况下才启动；

2. 也不是所有浏览器的preloader会把图片列为预加载的资源，可能它认为图片加载过于耗费带宽而不把它列为预加载资源之列；

3. preloader也并非最优，在某些浏览器中它会阻塞body的解析。因为有的浏览器将页面文档拆分为head和body两部分进行解析，在head没有解析完之前，body不会被解析。一旦在解析head的过程中触发了preloader，这无疑会导致head的解析时间过长。

Preloader在响应式设计中的问题

preloader的诞生本是出于一番好意，但好心也有可能办坏事。

filamentgroup有一种著名的响应式设计的图片解决方案 Responsive Design Images：

<html><head><title></title><script type="text/javascript" src="./responsive-images.js"></script></head><body><img src="./running.jpg?medium=_imgs/running.medium.jpg&large=_imgs/running.large.jpg"></body></html>

 它的工作原理是，当responsive-images.js加载完成时，它会检测当前显示器的尺寸，并且设置一个cookie来标记当前尺寸。同时你需要在服务器端准备一个.htaccess文件，接下来当你请求图片时，.htaccess中的配置会检测随图片请求异同发送的Cookie是被设置成medium还是large,这样也就保证根据显示器的尺寸来加载对于的图片大小。

很明显这个方案成功的前提是，js执行先于发出图片请求。但在Chrome下打开，你会发现执行顺序是这样：

responsive-images.js和图片几乎是同一时间发出的请求。结果是第一次打开页面给出的是默认小图，如果你再次刷新页面，因为Cookie才设置成功，服务器返回的是大图。

严格意义上来说在某些浏览器中这不一定是preloader引起的问题，但preloader引起的问题类似：插入脚本的顺序和位置或许是开发者有意而为之的，但preloader的这种“聪明”却可能违背开发者的意图，造成偏差。

如果你觉得上一个例子还不够说明问题的话，最后请考虑使用 picture(或者@srcset)元素的情况：

<picture><source src="med.jpg" media="(min-width: 40em)" /><source src="sm.jpg"/><img src="fallback.jpg" alt="" /></picture>

 在preloader搜寻到该元素并且试图去下载该资源时，它应该怎么办？一个正常的paser应该是在解析该元素时根据当时页面的渲染布局去下载，而当时这类工作不一定已经完成，preloader只是提前找到了该元素。退一步来说，即使不考虑页面渲染的情况，假设preloader在这种情形下会触发一种默认加载策略，那应该是"mobile first"还是"desktop first"？默认应该加载高清还是低清照片？

二. JS Loader

理想是丰满的，现实是骨感的。出于种种的原因，我们几乎从不直接在页面上插入js脚本，而是使用第三方的加载器，比如seajs或者requirejs。关于使用加载器和模块化开发的优势在这里不再赘述。但我想回到原点，讨论应该如何利用加载器，就从seajs与requirejs的不同聊起。

在开始之前我已经假设你对requirejs与seajs语法已经基本熟悉了，如果还没有，请移步这里：

• CMD标准： https://github.com/cmdjs/specification/blob/master/draft/module.md
• AMD标准： https://github.com/amdjs/amdjs-api/blob/master/AMD.md

BTW: 如果你还是习惯在部署上线前把所有js文件合并打包成一个文件，那么seajs和requirejs其实对你来说并无区别。

seajs与requirejs在模块的加载方面是没有差异的，无论是requirejs在定义模块时定义的依赖模块，还是seajs在factory函数中require的依赖模块，在会在加载当前模块时被载入，异步，并且顺序不可控。差异在于factory函数执行的时机。

执行差异

为了增强对比，我们在定义依赖模块的时候，故意让它们的factory函数要执行相当长的时间，比如1秒：

// dep_A.js定义如下，dep_B、dep_C定义同理

define(function(require, exports, module) {

    (function(second) {
        var start = +new Date();
        while (start + second * 1000 > +new Date()) {}
    })(window.EXE_TIME);

    // window.EXE_TIME = 1；此处会连续执行1s

    exports.foo = function() {
        console.log("A");
    }
})

 为了增强对比，设置了三组进行对照试验，分别是：

//require.js:
require(["dep_A", "dep_B", "dep_C"], function(A, B, C) {

});

//sea.js:
define(function(require, exports, module) {

    var mod_A = require("dep_A");
    var mod_B = require("dep_B");
    var mod_C = require("dep_C");
});

//sea.js(定义依赖但并不require):
define(["dep_A", "dep_B", "dep_C"], function(require, exports, module){

}

 接下来我们看看代码执行的瀑布图:

1.require.js：在加载完依赖模块之后立即执行了该模块的factory函数

2.sea.js: 下面两张图应该放在一起比较。两处代码都同时加载了依赖模块，但因为没有require的关系，第三张图中没有像第二张图那样执行耗时的factory函数。可见seajs执行的原则正如CMD标准中所述Execution must be lazy。

我想进一步表达的是，无论requirejs和seajs，通常来说大部分的逻辑代码都会放在模块的factory函数中，所以factory函数执行的代价是非常大的。但上图也同样告诉我们模块的define，甚至模块文件的Evaluate代价非常小，与factory函数无关。所以我们是不是应该尽可能的避免执行factory函数，或者等到我们需要的指定功能的时候才执行对应的factory函数？比如：

document.body.onclick = function () {
    require(some_kind_of_module);
}

 这是非常实际的问题，比如爱奇艺一个视频播放的页面，我们有没有必要在第一屏加载页面的时候就加载登陆注册，或者评论，或者分享功能呢？因为有非常大的可能用户只是来这里看这个视频，直至看完视频它都不会用到登陆注册功能，也不会去分享这个视频等。加载这些功能不仅仅对浏览器是一个负担，还有可能调用后台的接口，这样的性能消耗是非常可观的。

我们可以把这样称之为"懒执行"。虽然seajs并非有意实现如上所说的“懒执行”(它只是在尽可能遵循CommonJS标准靠近)。但“懒执行”确实能够有助于提升一部分性能。

但也有人会对此产生顾虑。

记得玉伯转过的一个帖子： SeaJS与RequireJS最大的区别。我们看看其中反对这么做的人的 观点：

我个人感觉requirejs更科学，所有依赖的模块要先执行好。如果A模块依赖B。当执行A中的某个操doSomething()后，再去依赖执行B模块require('B');如果B模块出错了，doSomething的操作如何回滚？ 很多语言中的import, include, useing都是先将导入的类或者模块执行好。如果被导入的模块都有问题，有错误，执行当前模块有何意义？

而依赖dependencies是工厂的原材料，在工厂进行生产的时候，是先把原材料一次性都在它自己的工厂里加工好，还是把原材料的工厂搬到当前的factory来什么时候需要，什么时候加工，哪个整体时间效率更高？

首先回答第一个问题。

第一个问题的题设并不完全正确，“依赖”和“执行”的概念比较模糊。编程语言执行通常分为两个阶段，编译(compilation)和运行(runtime)。对于静态语言(比如C/C++)来说，在编译时如果出现错误，那可能之前的编译都视为无效，的确会出现描述中需要回滚或者重新编译的问题。但对于 动态语言或者脚本语言，大部分执行都处在运行时阶段或者解释器中：假设我使用Nodejs或者Python写了一段服务器运行脚本，在持续运行了一段时间之后因为某项需求要加载某个(依赖)模块，同时也因为这个模块导致服务端挂了——我认为这时并不存在回滚的问题。在加载依赖模块之前当前的模块的大部分功能已经成功运行了。

再回答第二个问题。

对于“工厂”和“原材料”的比喻不够恰当。难道依赖模块没有加载完毕当前模块就无法工作吗？requirejs的确是这样的，从上面的截图可以看出，依赖模块总是先于当前模块加载和执行完毕。但我们考虑一下基于CommonJS标准的Nodejs的语法，使用require函数加载依赖模块可以在页面的任何位置，可以只是在需要的时候。也就是说当前模块不必在依赖模块加载完毕后才执行。

你可能会问，为什么要拿AMD标准与CommonJS标准比较，而不是CMD标准？

玉伯在 CommonJS 是什么这篇文章中已经告诉了我们CMD某种程度上遵循的就是CommonJS标准：

从上面可以看出，Sea.js 的初衷是为了让 CommonJS Modules/1.1 的模块能运行在浏览器端，但由于浏览器和服务器的实质差异，实际上这个梦无法完全达成，也没有必要去达成。

更好的一种方式是，Sea.js 专注于 Web 浏览器端，CommonJS 则专注于服务器端，但两者有共通的部分。对于需要在两端都可以跑的模块，可以 有便捷的方案来快速迁移。

其实AMD标准的推出同时也是遵循CommonJS，在requirejs官方文档的 COMMONJS NOTES中说道：

CommonJS defines a module format. Unfortunately, it was defined without giving browsers equal footing to other JavaScript environments. Because of that, there are CommonJS spec proposals for Transport formats and an asynchronous require.

RequireJS tries to keep with the spirit of CommonJS, with using string names to refer to dependencies, and to avoid modules defining global objects, but still allow coding a module format that works well natively in the browser.

CommonJS当然是一个理想的标准，但至少现阶段对浏览器来说还不够友好，所以才会出现AMD与CMD，其实他们都是在做同一件事，就是致力于前端代码更友好的模块化。所以个人认为依赖模块的加载和执行在不同标准下实现不同，可以理解为在用不同的方式在完成同一个目标， 并不是一件太值得过于纠结的事。

懒加载

其实我们可以走的更远，对于非必须模块不仅仅可以延迟它的执行，甚至可以延迟它的加载。

但问题是我们如何决定一个模块是必须还是非必须呢，最恰当莫过取决于用户使用这个模块的概率有多少。Faceboook早在09年的时候就已经注意到这个问题： Frontend Performance Engineering in Facebook : Velocity 2009，只不过他们是以样式碎片来引出这个问题。

假设我们需要在页面上加入A、B、C三个功能，意味着我们需要引入A、B、C对应的html片段和样式碎片(暂不考虑js)，并且最终把三个功能样式碎片在上线前压缩到同一个文件中。但可能过了相当长时间，我们移除了A功能，但这个时候大概不会有人记得也把关于A功能的样式从上线样式中移除。久而久之冗余的代码会变得越来越多。Facebook引入了一套静态资源管理方案(Static Resource Management)来解决这个问题：

具体来说是将样式的“声明”(Declaration)和请求(Delivery)请求，并且是否请求一个样式由是否拥有该功能的 html片段决定。

当然同时也考虑也会适当的合并样式片段，但这完全是基于使用算法对用户使用模块情况进行分析，挑选出使用频率比较高的模块进行拼合。

这一套系统不仅仅是对样式碎片，对js，对图片sprites的拼合同样有效。

你会不会觉得我上面说的懒加载还是离自己太远了？ 但然不是，你去看看现在的人人网个人主页看看

如果你在点击图中标注的“与我相关”、“相册”、“分享”按钮并观察Chrome的Timeline工具，那么都是在点击之后才加载对应的模块

三. Delay Execution

利用浏览器缓存

脚本最致命的不是加载，而是执行。因为何时加载毕竟是可控的，甚至可以是异步的，比如通过调整外链的位置，动态的创建脚本。但一旦脚本加载完成，它就会被立即执行(Evaluate Script)，页面的渲染也就随之停止，甚至导致在低端浏览器上假死。

更加充分的理由是，大部分的页面不是Single Page Application，不需要依靠脚本来初始化页面。服务器返回的页面是立即可用的，可以想象我们初始化脚本的时间都花在用户事件的绑定，页面信息的丰满(用户信息，个性推荐)。 Steve Souders发现在Alexa上排名前十的美国网站上的js代码，只有29%在window.onload事件之前被调用，其他的71%的代码与页面的渲染无关。

Steve Souders的 ControlJS是我认为一直被忽视的一个加载器，它与Labjs一样能够控制的脚本的异步加载，甚至(包括行内脚本，但不完美)延迟执行。它延迟执行脚本的思路非常简单：既然只要在页面上插入脚本就会导致脚本的执行，那么在需要执行的时候才把脚本插入进页面。但这样一来脚本的加载也被延迟了？不，我们会通过其他元素来提前加载脚本，比如img或者是object标签，或者是非法的mine type的script标签。这样当真正的脚本被插入页面时，只会从缓存中读取。而不会发出新的请求。

Stoyan Stefanov在它的文章 Preload CSS/JavaScript without execution中详细描述了这个技巧, 如果判断浏览器是IE就是用image标签，如果是其他浏览器，则使用object元素：

window.onload = function () {

    var i = 0,
        max = 0,
        o = null,

        preload = [
            // list of stuff to preload    
        ],

        isIE = navigator.appName.indexOf('Microsoft') === 0;

    for (i = 0, max = preload.length; i < max; i += 1) {

        if (isIE) {
            new Image().src = preload[i];
            continue;
        }
        o = document.createElement('object');
        o.data = preload[i];

        // IE stuff, otherwise 0x0 is OK
        //o.width = 1;
        //o.height = 1;
        //o.style.visibility = "hidden";
        //o.type = "text/plain"; // IE 
        o.width  = 0;
        o.height = 0;


        // only FF appends to the head
        // all others require body
        document.body.appendChild(o);
    }

};

 同时它还列举了其他的一些尝试，但并非对所有的浏览器都有效，比如：

• 使用<link>元素加载script，这么做在Chrome中的风险是，在当前页有效，但是在以后打开需要使用该脚本的页面会无视该文件为缓存

• 改变script标签外链的type值，比如改为text/cache来阻止脚本的执行。这么做会导致在某些浏览器(比如FF3.6)中压根连请求都不会发出

type=prefetch

延迟执行并非仅仅作为当前页面的优化方案，还可以为用户可能打开的页面提前缓存资源，如果你对这两种类型的link元素熟悉的话：

• <link rel="subresource" href="jquery.js">: subresource类型用于加载当前页面将使用(但还未使用)的资源(预先载入缓存中)，拥有较高优先级

• <link rel="prefetch" href="http://NextPage.html">: prefetch类型用于加载用户将会打开页面中使用到的资源，但优先级较低，也就意味着浏览器不做保证它能够加载到你指定的资源。

那么上一节延迟执行的方案就可以作为subresource与prefeth的回滚方案。同时还有其他的类型：

• <link rel="dns-prefetch" href="//host_name_to_prefetch.com">: dns-prefetch类型用于提前dns解析和缓存域名主机信息，以确保将来再请求同域名的资源时能够节省dns查找时间，比如我们可以看到淘宝首页就使用了这个类型的标签:

• <link rel="prerender" href="http://example.org/index.html">: prerender类型就比较霸道了，它告诉浏览器打开一个新的标签页(但不可见)来渲染指定页面，比如这个 页面:

这也就意味着如果用户真的访问到该页面时，就会有“秒开”的用户体验。

但现实并非那么美好，首先你如何能预测用户打开的页面呢，这个功能更适合阅读或者论坛类型的网站，因为用户有很大的概率会往下翻页；要注意提前的渲染页面的网络请求和优先级和GPU使用权限优先级都比其他页面的要低，浏览器对提前渲染页面类型也有一定的要求，具体可以参考 这里

利用LocalStorage

在聊如何用它来解决我们遇到的问题之前，个人觉得首先应该聊聊它的优势和劣势。

Chris Heilmann在文章 There is no simple solution for local storage中指出了一些常见的LS劣势，比如同步时可能会阻塞页面的渲染、I/O操作会引起不确定的延时、持久化机制会导致冗余的数据等。虽然Chirs在文章中用到了比如"terrible performance", "slow"等字眼，但却没有真正的指出究竟是具体的哪一项操作导致了性能的低下。

Nicholas C. Zakas于是写了一篇针对该文的文章 In defense of localStorage，从文章的名字就可以看出，Nicholas想要捍卫LS，毕竟它不是在上一文章中被描述的那样一无是处，不应该被抵制。

比较性能这种事情，应该看怎么比，和谁比。

就“读”数据而言，如果你把“从LS中读一个值”和“从Object对象中读一个属性”相比，是不公平的，前者是从硬盘里读，后者是从内存里读，就好比让汽车与飞机赛跑一样，有一个benchmark各位可以参考一下： localStorage vs. Objects:

跑分的标准是OPS(operation per second)，值当然是越高越好。你可能会注意到，在某个浏览器的对比列中，没有显示关于LS的红色列——这不是因为统计出错，而是因为LS的操作性能太差，跑分太低(相对从Object中读取属性而言)，所以无法显示在同一张表格内，如果你真的想看的话，可以给你看一张放大的版本：

这样以来你大概就知道两者在什么级别上了。

在浏览器中与LS最相近的机制莫过于Cookie了：Cookie同样以key-value的形式进行存储，同样需要进行I/O操作，同样需要对不同的tab标签进行同步。同样有benchmark可以供我们进行参考： localStorage vs. Cookies

从Brwoserscope中提供的结果可以看出，就Reading from cookie, Reading from localStorage getItem, Writing to cookie,Writing to localStorage property四项操作而言，在不同浏览器不同平台，读和写的效率都不太相同，有的趋于一致，有的大相径庭。

甚至就LS自己而言，不同的存储方式和不同的读取方式也会产生效率方面的问题。有两个benchmark非常值得说明问题：

1. localStorage-string-size

2. localStorage String Size Retrieval

在第一个测试中，Nicholas在LS中用四个key分别存储了100个字符，500个字符，1000个字符和2000个字符。测试分别读取不同长度字符的速度。结果是： 读取速度与读取字符的长度无关。

第二个测试用于测试读取1000个字符的速度，不同的是对照组是一次性读取1000个字符；而实验组是从10个key中(每个key存储100个字符)分10次读取。结论:  是分10此读取的速度会比一次性读取慢90%左右。

LS也并非没有痛点。大部分的LS都是基于同一个域名共享存储数据，所以当你在多个标签打开同一个域名下的站点时，必须面临一个同步的问题，当A标签想写入LS与B标签想从LS中读同时发生时，哪一个操作应该首先发生？为了保证数据的一致性，在读或者在写时 务必会把LS锁住(甚至在操作系统安装的杀毒软件在扫描到该文件时，会暂时锁住该文件)。因为单线程的关系，在等待LS I/O操作的同时，UI线程和Javascript也无法被执行。

但实际情况远比我们想象的复杂的多。为了提高读写的速度，某些浏览器(比如火狐)会在加载页面时就把该域名下LS数据加载入内存中，这么做的副作用是延迟了页面的加载速度。但如果不这么做而是在临时读写LS时再加载，同样有死锁浏览器的风险。并且把数据载入内存中也面临着将内存同步至硬盘的问题。

上面说到的这些问题大部分归咎于内部的实现，需要依赖浏览器开发者来改进。并且并非仅仅存在于LS中，相信在IndexedDB、webSQL甚至Cookie中也有类似的问题在发生。

实战开始

考虑到移动端网络环境的不稳定，为了避免网络延迟(network latency)，大部分网站的移动端站点会将体积庞大的类库存储于本地浏览器的LS中。但 百度音乐将这个技术也应用到了PC端，他们将所依赖的jQuery类库存入LS中。用一段很简单的 代码来保证对jQuery的正确载入。我们一起来看看这段代码。代码详解就书写在注释中了：

!function (globals, document) {
    var storagePrefix = "mbox_";
    globals.LocalJs = {
        require: function (file, callback) {
            /*如果无法使用localstorage，则使用document.write把需要请求的脚本写在页面上
                作为fallback，使用document.write确保已经加载了所需要的类库
            */

            if (!localStorage.getItem(storagePrefix + "jq")) {
                document.write('<script src="' + file + '" type="text/javascript"></script>');
                var self = this;

            /*
                并且3s后再请求一次，但这次请求的目的是为了获取jquery源码，写入localstorage中(见下方的_loadjs函数)
                这次“一定”走缓存，不会发出多余的请求
                为什么会延迟3s执行？为了确保通过document.write请求jQuery已经加载完成。但很明显3s也并非一个保险的数值
                同时使用document.write也是出于需要故意阻塞的原因，而无法为其添加回调，所以延时3s
            */
                setTimeout(function () {
                    self._loadJs(file, callback)
                }, 3e3)
            } else {
                // 如果可以使用localstorage，则执行注入
                this._reject(localStorage.getItem(storagePrefix + "jq"), callback)
            }
        },
        _loadJs: function (file, callback) {
            if (!file) {
                return false
            }
            var self = this;
            var xhr = new XMLHttpRequest;
            xhr.open("GET", file);
            xhr.onreadystatechange = function () {
                if (xhr.readyState === 4) {
                    if (xhr.status === 200) {
                        localStorage.setItem(storagePrefix + "jq", xhr.responseText)
                    } else {}
                }
            };
            xhr.send()
        },
        _reject: function (data, callback) {
            var el = document.createElement("script");
            el.type = "text/javascript";
            /*关于如何执行LS中的源码，我们有三种方式
                1. eval
                2. new Function
                3. 在一段script标签中插入源码，再将该script标签插入页码中

                关于这三种方式的执行效率，我们内部初步测试的结果是不同的浏览器下效率各不相同
                参考一些jsperf上的测试，执行效率甚至和具体代码有关。
            */
            el.appendChild(document.createTextNode(data));
            document.getElementsByTagName("head")[0].appendChild(el);
            callback && callback()
        },
        isSupport: function () {
            return window.localStorage
        }
    }
}(window, document);
!
function () {
    var url = _GET_HASHMAP ? _GET_HASHMAP("/player/static/js/naga/common/jquery-1.7.2.js") : "/player/static/js/naga/common/jquery-1.7.2.js";
    url = url.replace(/^\/\/mu[0-9]*\.bdstatic\.com/g, "");
    LocalJs.require(url, function () {})
}(); 

 因为桌面端的浏览器兼容性问题比移动端会严峻的多，所以大多数对LS利用属于“做加法”，或者“轻量级”的应用。最后一瞥不同站点在PC平台的对LS的使用情况：

• 比如百度和github用LS记录用户的搜素行为，为了提供更好的搜索建议

• Twitter利用LS最主要的记录了与用户关联的信息(截图自我的Twitter账号，因为关注者和被关注者的不同数据会有差异)：
• userAdjacencyList表占40,158 bytes，用于记录每个字关联的用户信息
• userHash表占36,883 bytes，用于记录用户被关注的人信息

• Google利用LS记录了样式：

• 天猫用LS记录了导航栏的HTML碎片代码：

总结

No silver bullet.没有任何一项技术或者方案是万能的，虽然开源社区和浏览器厂商在提供给我们越来越丰富的资源，但并不意味着今后遇见的问题就会越来越少。相反，或许正因为多样性，和发展中技术的不完善，事情会变得更复杂，我们在选择时要权衡更多。我无意去推崇某一项解决方案，我想尽可能多的把这些方案与这些方案的厉害呈现给大家，毕竟不同人考虑问题的方面不同，业务需求不同。

还有一个问题是，本文描述的大部分技术都是针对现代浏览器而言，那么如何应对低端浏览器呢？

从百度统计这张17个月的浏览器市场份额图中可以看出(当然可能因为不同站点的用户特征不同会导致使用的浏览器分布与上图有出入)，我们最关心的IE6的市场份额一直是呈现的是下滑的趋势，目前已经降至几乎与IE9持平；而IE9在今年的市场份额也一直稳步上升；IE7已经被遥遥甩在身后。领头的IE8与Chrome明显让我们感受到有足够的信心去尝试新的技术。还等什么，行动起来吧！

转自: http://www.infoq.com/cn/articles/browser-resource-loading-optimization

从事java EE开发4年多了，从2011年尾开始参与一个大型电子商务系统，一直做到现在。项目在2012年10月完成了验收，2012年11月开始转运维，巧的是自己跟另外一个同事被客户指定为长期固定运维人员。就这样开始了1年多了运维工作。虽说是运维，但我们不需要管理服务器，不需要管理数据库，做的工作就是修改上生产后项目出现的一些问题（处理用户报障），同时开发一些新的需求（开发新功能），以及不断的优化重构项目源码，处理一些原功能存在的严重性能问题，提炼或从新定义共用的业务API等。

下面列举一些我这1年多运维工作中碰到的一些常见的不规范的代码。（之前有整理过文档，所以现在写这个博文一些内容直接copy过来的）

一、存在警告的代码。

1、冗余转换。 

2、集合类未使用泛型。 

3、定义未使用的变量或方法。 

4、import引入了过多的未用到的类。 

二、其它不规范的代码

5、在spring容器中存在的bean却使用new方式来构建实例。 

6、业务层捕获了异常却不抛出，导致事物无法回滚，而且异常没有抛出，但功能出错时，使用火狐的firebug插件也看不到错误信息，加大的代码的调式难度。

7、大量定义辅助性的vo类。（个人建议，开发业务功能时，尽可能使用pojo，封装数据或接收参数pojo搞不定的时候使用Map<String, Object>，而不用再定义一个java类，因为里面大量的字段跟pojo是重复的，大量的setter，getter操作也影响性能）

8、NullPointException，在对一个对象进行使用前，没有判断是否非空导致的空指针异常。

9、业务代码写到了controller层。（这样写不但降低了代码的可读性，而且如果controller中写了增、删、改的业务代码时也破坏了事物的完整性，一些对spring理解不深，对事物控制没什么概念的新手经常这样搞）

10、常量类的大量重复定义。（开发时可能各个开发人员很少去看别人的代码，如果项目经理没有统筹规范好的话，很容易导致开发人员自己定义常量自己用，而有些常量是整个系统可以共用的，大量的重复定义加大了维护的难度。）

11、在js中拼写HTML代码。（对于很多jQuery用的不熟的新手经常这样搞）

12、与金额有关的字段，很多被定义成了double类型，其实double是存在精度问题的，应该采用BigDecimal替换之。（运维期修改了很多这样的代码）

以上列举了12种常见的不规范代码，下面我贴一些代码举例说明。

1、冗余转换。

上图中因为List使用了泛型，下面的for循环中就不需要强制转型了。（当然转了也不会有错） 

2、集合类未使用泛型。 

 

 上诉报警告的代码虽然也没错，但jdk1.5就推出了泛型，所以用集合类时应该养成使用泛型的习惯。

3、定义未使用的变量或方法。

 上诉报警告的代码编译也不会错，但是既然一个变量定义了没有用到，就应该删掉。

多定义一个变量，应该就会多占用一点内存。

4、import引入了过多的未用到的类。 

 

 这个问题同样也不会引起编译错误，但没用到的类没必要引入进来。可通过按ctrl+shift+o来去除多余的import，也可通过设置eclipse，在保存java文件时自动删除这些多余的import，eclipse的设置方式如下图：

5、在spring容器中存在的bean却使用new方式来构建实例。 

我见的最多的是使用在业务bean中注入dataSource，然后new 一个JdbcTemplate对象，其实JdbcTemplate对象也是在spring定义了的，所以直接注入JdbcTemplate对象即可。而且spring容器默认的bean的scope是single=true，即单实例，直接注入JdbcTemplate对象可以避免大量JdbcTemplate实例占用内存（虽然会被gc自动回收掉）。

如下图：

 上图注入的是一个dataSource，其实可以直接注入JdbcTemplate对象的，因为JdbcTemplate对象也定义在了spring容器中，见下图：

所以前面的代码可修改为直接注入JdbcTemplate对象，修改后如下图：

6、业务层捕获了异常却不抛出。

 直接打印了一下，写这样代码的开发人员明显是刚从学校出来的。

7、大量定义辅助性的vo类。

 如上图代码，会员各种数据按业务需要分别存放在dealer表跟dealer_personal_info表，当视图层需要会员数据时，需要将这两个表的一些数据进行返回。一些开发人员首先想到的就是新建一个vo类，里面定义好视图层需要的所有字段，然后从数据库查询数据封装好这个vo类并进行返回。这样做其实对性能影响挺大的，特别当查询很多数据，在一个循环里大量的setter getter。让我来重构这个代码，首先我就会删掉DealerInfoVo.java这个类，然后将会员数据封装到一个Map<String, Object>中，然后返回给视图层使用。

修改后的代码如下图：

 现在都流行“约定优于配置”，更应该采用Map的方式。

8、NullPointException，在对一个对象进行使用前，没有判断是否非空导致的空指针异常。

这个不举例了，有个1年开发经验的朋友都知道。

9、业务代码写到了controller层。

有开发经验的朋友都应该知道业务代码不能写在controller层，而要写到业务层或说应用层。

10、常量类的大量重复定义。

为避免大量重复的枚举常量定义，我的建议及现在的做法就是使用枚举类。首先把所有数据表字段有枚举值的字段定义一个枚举类，在开发时告知大家对于数据表枚举字段不允许定义常量，而要统一使用对应的枚举类。

以上是个人这些年的一些开发经验总结和见解，特同大家分享，欢迎指正，讨论。

程序员世界里有哪些名言呢?Jun Auza 列出了一些启迪人心的至理名言，它们大多来自产业界富于经验的人们。
下文列出前10个供读者欣赏：
10. “People think that computer science is the art of geniuses but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones”——Donald Knuth
10. “人们认为计算机科学是天才的艺术，但事实完全相反：只是很多人在共同建立起来的事物之上工作，就像一条由小石头铺成的小径。”——Donald Knuth

9. “First learn computer science and all the theory. Next develop a programming style. Then forget all that and just hack”——George Carrette
9. “首先学会计算机科学和所有的理论，然后发展出一个编程风格，之后便要忘掉所有这些，以自由的方式探索。”——George Carrette

8. “Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris”——Larry Wall
8. “大多数的你们都熟悉程序员的美德，它们有三点：懒、不耐烦、以及狂妄自大。”——Larry Wall

7. “Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other,with no structural integrity， but just done by brute force and thousands of slaves”——Alan Kay
7. “今日的大多数软件很像埃及金字塔，由千百万砖头堆砌起来，层层相切，没有着整体的结构，是由畜力和成千上万奴隶的力量建立起来的。”——Alan Kay

6. “The trouble with programmers is that you can never tell what a programmer is doing until it’s too late”——Seymour Cray
6. “程序员的问题是，不到太晚，你永远无法知道一个他在做着些什么。”——Seymour Cray

5. “To iterate is human, to recurse divine”——L. Peter Deutsch
5. “人理解迭代，神理解递归。”——Peter Deutsch

4. “On two occasions I have been asked [by members of Parliament]: ‘Pray， Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question”——Charles Babbage
4. “有两次我被(国会议员)问道：‘ Mr. Babbage，如果你输入计算机错误的数据，正确的答案会出来吗?’

我完全无法理解能产生此种问题的大脑的混乱。”——Charles Babbage

3. “Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program”——Linus Torvalds
3. “大部分好的程序员编程并不是为了钱或名望，而只是因为纯粹的乐趣。”——Linus Torvalds

2. “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”——Martin Golding
2. “编程的时候，总是想着那个维护你代码的人会是一个知道你住在哪儿的有暴力倾向的精神病患者。”——Martin Golding

1. “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies”—— C.A.R. Hoare
1. “有两种生成一个软件设计方案的途径。一个是把它做得如此简单，以致于明显不会有漏洞存在。另一个是把它做的如此复杂，以致于不会有明显的漏洞存在。”——C.A.R. Hoare

看到ITFriend中有些小伙伴刚进入公司，面对大量的项目代码，往往手足无措，有点慌，我说下我的经历。

声明：我从事的是C++开发工作，阅读的代码都是基于客户端/服务器的，以下谈的是C++项目代码的阅读方法多些

希望懂java的小伙伴分享下java公司项目代码的阅读方法，小弟感激不尽。

    编译代码把项目跑起来  代码到手以后，先尝试着编译一下，无非就是库的配置，库路径的配置，缺少某个文件，或者头文件包含路径不正确，一般公司给你的代码都可以编译成功，windows平台下一般使用vs工具来编译，集成调试工具，而Linux下编译.使用gcc（g++）编译器 make工具或者automake工具，具体用法在搜索引擎上能找到。编译成功以后把项目跑起来，我喜欢看看客户端长啥样，哈哈，恭喜你，迈出了第一步

     看项目文档，和项目开发人员（维护人员）进行沟通    公司的项目代码会有相关的设计文档，比如XX项目概要设计文档、XX项目详细设计文档、XX项目模块设计以及之间依赖关系的文档等等，通过这些文档，软件开发人员起码对项目有个整体的认识，比如项目本身是解决什么领域问题的？有哪些功能模块以及他们的大体功能是什么？使用了什么开源库？通过文档还可以了解到代码中的一些数据结构的详细注释，网络传输是如何设计的，使用了哪些协议？数据库中的字段是如何设计的，以及数据库中各个表之间的关系。在看代码的过程中，遇到模糊不清或者自己拿不住的代码，要及时和同事沟通，他们对代码的熟悉程度比我们强，虚心有礼貌的问人家。否则自己在那憋着瞎猜代码的含义，费时费力还得不偿失，开口求人帮忙就那么难？嘻嘻，你帮我下，我帮你下，咱俩慢慢就熟悉了嘛

     搞清楚程序的流程和大体框架，具体功能模块具体分析    从main函数开始，把客户端和服务器怎么工作的流程大致的看一下，客户端如何连接服务器段的？服务器客户端是如何进行数据交互的？在关键的地方下断点，看看客户端发送来的内容是什么，服务器在接收到客户端发送来的消息后是如何处理的。

个人建议，先把程序的流程和整体框架搞懂一点，明白一些函数大概是实现什么功能就可以，现在不要去过多的关注和沉迷在功能模块的实现细节中，当需要定位到具体的某个功能实现模块的时候，再切换到函数实现中一点点分析代码就ok。如果对某个地方不太清楚，可以自己修改下源代码，运行一下看看运行的结果怎样。我刚开始的时候不敢改源代码，怕改错了项目就不好使了，领导会骂我，先拷贝一份编译好的源代码，然后随意改，反正我还有一份备份的源代码，我不怕。

     个人兴趣驱动或者debug驱动方式来看代码    说实话，单纯的看代码真心没劲枯燥，而且效率不高。我们可以自我驱动看代码，比如思考某个功能是如何实现的呢？然后猜测可能是如何实现的，然后再项目代码中一点点去跟踪源代码，慢慢的剥茧抽丝，相信你会有恍然大悟的感觉。还有一种就是公司会用改bug的方式来驱动你熟悉代码，我刚进公司的时候就是这样，解决一个bug后，不仅仅对于项目整体流程熟悉了，也对其中的几个模块熟悉了，一举两得。

    UML帮助我们整理思路    使用UML帮助我们整理思维，使用类图来分析类与类之间的关系，使用UML里的活动图，配合IDE工具分析核心业务流程，理解软件是如何工作的。使用UML来整理程序流程这招，还是在我进入公司以后，带我的老师教我的，个人感觉非常受益，程序开发人员在初期的时候可能对于画UML图有点不适应，慢慢就习惯了。对于整理思路挺有帮助的，希望大家养成个好习惯，嘻嘻。
     具体的模块分析    对需要的具体的代码进行详细分析。搞清变量的意义和关联关系，搞清实现的逻辑和算法。好的代码，此处是会有注释的。可以自己F11走到项目代码中，然后单步调试，看看每个变量是如何变化的，会加深对这个函数中的逻辑和算法的理解。

     心理状态的调整    项目源代码的代码量多没啥，但是我们自己心里不要着急，慢慢来，自己努力的功夫到了，多花点时间在看代码思考代码上，公司的代码会被你一点点啃透的。如果遇到看不懂代码的情况，就分析下自己为什么看不懂？是项目使用了自己不熟悉的设计模式？还是一些业务领域基础知识自己没有掌握（比如我自己做视频服务器开发，就需要看很多资料去了解视频格式，视频压缩，视频编码以及视频传输的一些协议）？或者是自己对项目框架的理解不对导致的，要自己主动的分析

ps：有一本《代码阅读方法和实践》（code reading），会教你怎样去阅读源代码。