最近由于需要用到ThreadLocal，在网上搜索了一些相关资料，发现对ThreadLocal经常会有下面几种误解

 一、ThreadLocal是java线程的一个实现
      ThreadLocal的确是和java线程有关，不过它并不是java线程的一个实现，它只是用来维护本地变量。针对每个线程，提供自己的变量版本，主要是为了避免线程冲突，每个线程维护自己的版本。彼此独立，修改不会影响到对方。

 二、ThreadLocal是相对于每个session的

        ThreadLocal顾名思义，是针对线程。在java web编程上，每个用户从开始到会话结束，都有自己的一个session标识。但是ThreadLocal并不是在会话层上。其实，Threadlocal是独立于用户session的。它是一种服务器端行为，当服务器每生成一个新的线程时，就会维护自己的ThreadLocal。对于这个误解，个人认为应该是开发人员在本地基于一些应用服务器测试的结果。众所周知，一般的应用服务器都会维护一套线程池，也就是说，对于每次访问，并不一定就新生成一个线程。而是自己有一个线程缓存池。对于访问，先从缓存池里面找到已有的线程，如果已经用光，才去新生成新的线程。所以，由于开发人员自己在测试时，一般只有他自己在测，这样服务器的负担很小，这样导致每次访问可能是共用同样一个线程，导致会有这样的误解：每个session有一个ThreadLocal

 三、ThreadLocal是相对于每个线程的，用户每次访问会有新的ThreadLocal

  理论上来说，ThreadLocal是的确是相对于每个线程，每个线程会有自己的ThreadLocal。但是上面已经讲到，一般的应用服务器都会维护一套线程池。因此，不同用户访问，可能会接受到同样的线程。因此，在做基于TheadLocal时，需要谨慎，避免出现ThreadLocal变量的缓存，导致其他线程访问到本线程变量

 四、对每个用户访问，ThreadLocal可以多用
        可以说，ThreadLocal是一把双刃剑，用得来的话可以起到非常好的效果。但是，ThreadLocal如果用得不好，就会跟全局变量一样。代码不能重用，不能独立测试。因为，一些本来可以重用的类，现在依赖于ThreadLocal变量。如果在其他没有ThreadLocal场合，这些类就变得不可用了。个人觉得ThreadLocal用得很好的几个应用场合，值得参考

  1、存放当前session用户：quake want的jert

  2、存放一些context变量，比如webwork的ActionContext

  3、存放session，比如Spring hibernate orm的session

       说真的，对于spring提供AOP的功能，个人实在不敢太过于恭维。主要是Spring的AOP功能没那么强大，而且必须是对于spring容器管理的bean才能实施AOP功能，对于容器外的bean就无能为力了。而且spring没有提供属性的AOP功能。在这些方面，spring AOP真的不能和Aspectj相比。Aspectj的AOP功能才真的是真正意义的AOP框架，提供的功能非常强大，几乎可以实现任何类型的AOP。不过Aspectj的学习曲线相对要比spring AOP稍微陡峭一点，主要是spring AOP可以当成普通javabean来处理，而Aspectj还要另外做编译器，比较麻烦。不过，庆幸的是，eclipse下面有Aspectj插件，开发起来也是很方便。所以一般，复杂的AOP功能，还是推荐用Aspectj

     对于一般的J2EE开发来说，要实现一些比较常用的AOP，Spring 还是能满足的。比如事务、异常、日志、权限等等，在这些方面，spring AOP还是比较方便的，特别是事务处理，spring提供了相当好的集成。如果事务处理用Aspectj来实现，不见得好多少。

    一直以来，觉得spring AOP最好用的一个地方就是提供了BeanNameAutoProxyCreator，这个类真的非常方便，以至于个人一旦遇到要实现AOP，首先就是求组于BeanNameAutoProxyCreator，如果BeanNameAutoProxyCreator实现不了，再考虑别的。不过，一般情况来说，BeanNameAutoProxyCreator的确能满足需要了，除非你的需求真的千奇百怪。

   在应用spring AOP功能时，优先考虑用接口。因为如果用接口的话，那么spring会创建一个代理，并在代理里面实现AOP增强代码，并调用真正的实例对象。不过，spring AOP功能不一定非要用接口，一些普通类也是可以的。对于普通类，spring会用CGLIB来动态生成一个新类。并且CGLIB会保持一个生成类的cache,因此它不会一直生成新类。spring使用ProxyCallbackFilter对象把其它对象放进map进行管理。如果没有管理好cache，将会产生大量的java对象，直至出现OutOfMemoryErrors。因此使用spring的aop时，一定要正确实现equals and hashCode。

   不过，不管怎么样，在应用spring AOP时，还是优先考虑接口方式，毕竟面向接口方式还是值得推荐的一个编程思想。

     最近在负责一个大项目，项目组成员包括项目经理大概10个人左右。项目技术用struts+spring+hibernate实现。项目的规模相对来说是比较大的，总共有10大模块，每个大模块又分为有十几个、甚至几十个小模块。开发工具用eclipse，由于在开发阶段，项目开发成员需要频繁重启服务器。在启动服务器的时候，每次启动时间总是会超过1分钟。记得以前在做另外一个项目时，启动时间不到5秒钟，相差了10倍，而且项目规模是差不多的。

    从初步分析来说，应该是hibernate解释hbm.xml时花费时间，或者可能是spring容器启动并解释所有的bean配置文件。诊断了一下，发现1分钟消耗的时间主要分布在hibernate解释hbm.xml花费5秒；spring容器从启动到解释bean配置文件竟然花了58秒，真是太嚣张了。当时非常怀疑spring的效率问题。企图从网上搜索相关资料，看看有什么优化措施。

    首先是找到了hibernate的启动优化 http://www.hibernate.org/194.html  里面的主要思想是通过将xml序列花到本地的文件里，每次读取的时候根据情况，从本地文件读取并反序列化，节省了hibernate xml的解析时间。按照这个方式测试了一下，发现hibernate的启动时间从5秒降低到3秒，但是这个优化对于整个启动过程是杯水车薪的，毫无用处。

    没办法，又仔细查看了spring的资料，终于发现spring的容器是提供了lazy-load的，即默认的缺省设置是bean没有lazy-load，该属性处于false状态，这样导致spring在启动过程导致在启动时候，会默认加载整个对象实例图，从初始化ACTION配置、到service配置到dao配置、乃至到数据库连接、事务等等。这么庞大的规模，难怪spring的启动时间要花将近1分钟。尝试了一下，把beans的default-lazy-init改为true就，再次启动，速度从原来的55秒，降到8秒钟！！Great！虽然是非常小一个改动，但是影响确实非常大。一个项目组10个人，假若每个人一天平均需要在eclipse下启动测试服务器50次。那么一天项目组需要重启500次，每次节省50秒的话，就是25000秒，将近几个小时，差不多一个工作日，多么可观的数字！

   不过在运行期间第一次点页面的时候，由于spring做了lazy-load，现在就需要启动一部分需要的beans，所以稍微慢2－3秒钟，但是明显比等几十秒要快很多，值得一鉴。

    以上是针对开发阶段的spring容器启动优化，在部署到实际环境中，倒是没必要设置为lazy-load。毕竟部署到实际环境中不是经常的事，每次启动1分钟倒不是大问题。        上面说到代码混淆方法之混淆器使用，主要针对proguard进行了说明。其实，只要我们的类被其他地方的类调用到的话，那么代码混淆器就似乎没有办法了，因为代码混淆如果把代码的签名一起改了的话，其他地方是肯定调用不到，并会出错。而且，针对代码调用，有几点是我们肯定不能避免的：一是jsp页面，如果在jsp页面调用了某个类，那么如果类被混淆了的话，jsp页面肯定会出错；二是xml配置文件，比如在hibernate开发中，对于hbm.xml文件，就没办法了。不过，很庆幸的是，proguard的功能很强，可以通过配置，只针对私有方法、私有变量做混淆。但是，这种混淆效果肯定是不如所愿。下面将说明代码混淆方法之二（tomcat下面代码加密）

       应用服务器加密的方法不外就是通过修改该应用服务器的类转载器，来载入我们的类。首先我们通过一定算法，将我们的class文件加密，并部署到应用服务器。然后修改修改该应用服务器的类转载器，通过解密算法将class文件反编译并加载。从而达到class文件的加密。下面主要针对tomcat下面的加密、解密说明。

     首先得研究一下tomcat的类装载机制：tomcat的类装载机制主要分为下面几种：

   1、Bootstrap： 由虚拟机提供
   2、System：类路径等相关
   3、Common：tomcat下面的公共包
   4、Catalina：tomcat自己的包，比如server目录下面
   5、Shared：各个war包的共享包
   6、Webapp：各个war包自己的相关类包

   由于一般的典型情况是，我们是要加密自己的应用程序，那么，我们就要覆盖上面所说的Webapp类装载器。tomcat的Webapp类装载器位于${tomcat.home}\server\lib\catalina.jar下面的类org.apache.catalina.loader.WebappClassLoader。我们从tomcat的网站下面下载tomcat的源代码，WebappClassLoader的源代码位于目录\jakarta-tomcat-catalina\catalina\src\share\org\apache\catalina\loader下面，打开源代码，可以看到里面的调用机制是这样的：
     该类里面提供了很多诸如addRepository、addJar之类的方法，这是tomcat给类路径添加相应的目录和包，比如在启动时，tomcat会将我们的应用程序下面的WEB-INF/lib/*.jar和WEB-INF/classes/**.class添加到资源路径下面。
    
    首先，在加载类的时候，会调用loadClass方法。我们先定位到下面这个方法   
     public Class loadClass(String name, boolean resolve)
        throws ClassNotFoundException 

     仔细观察该方法，可以发现，tomcat提供了很多缓存机制，首先分别从各个级别的缓存加载类，如果加载到类，就直接返回，否则会调用下面的方法： clazz = findClass(name);

     继续定位到方法 public Class findClass(String name) throws ClassNotFoundException 
     该方法里面有一句调用 clazz = findClassInternal(name); 这个很关键，也就是我们最需要关心的一个方法了。再仔细阅读一下，就能发现，tomcat从本地的资源库里面找，并先查找资源缓存，如果找到的话，直接返回缓存类。若找不到，就会读取类文件的byte[]数组，并最后调用defineClass方法。defineClass文件是类装载的最后一个类定义方法。下面就是findClassInternal方法的代码小段

           if (entry.loadedClass == null) {
            synchronized (this) {
                if (entry.loadedClass == null) {
                 
                  clazz = defineClass(name, entry.binaryContent, 0,
                                        entry.binaryContent.length,
                                        codeSource);               
                 }
                    entry.loadedClass = clazz;
                    entry.binaryContent = null;
                    entry.source = null;
                    entry.codeBase = null;
                    entry.manifest = null;
                    entry.certificates = null;
                } else {
                    clazz = entry.loadedClass;
                }
            }
        } else {
            clazz = entry.loadedClass;
        }

      entry是一个存放类属性的bean，其中类的数组流存放在binaryContent，那么我们的加密解密就从这里入手。为了方便起见，我们用base64算法加密，加密方法很简单。通过调用base64加密方法，把原有的class文件加密；推荐的base64加密方法是commons包的codec工程。可以从apache上面下载。把加密后的class文件替换tomcat下面的部署类文件。 那么在类装载时就可以解密，并加载了。例如，为了测试，个人只对OrganizationServiceImp.class进行加密，那么通过修改以上的装载方法，就可以实现解密，修改后的代码为如下，其中黑体为修改的

        if (entry.loadedClass == null) {
            synchronized (this) {
                if (entry.loadedClass == null) {
                 
                 if(name.indexOf("OrganizationServiceImp") >=0)
                 {
                    byte[] base64Array = entry.binaryContent;
                    byte[] orginByteArray = Base64.decodeBase64(base64Array);
                    clazz = defineClass(name, orginByteArray, 0,
                      orginByteArray.length, 
                               codeSource);
                 }
                 else
                 {
                  clazz = defineClass(name, entry.binaryContent, 0,
                                        entry.binaryContent.length,
                                        codeSource);
                                       
                 }
                    entry.loadedClass = clazz;
                    entry.binaryContent = null;
                    entry.source = null;
                    entry.codeBase = null;
                    entry.manifest = null;
                    entry.certificates = null;
                } else {
                    clazz = entry.loadedClass;
                }
            }
        } else {
            clazz = entry.loadedClass;
        }
      
      运行服务器，一切正常，说明解密、加密成功，到此完成tomcat服务器下面的解密、加密。可以看出，tomcat下面的类装载机制其实挺简单，不像其他服务器，比如weblogic、websphere服务器那么复杂。若能在这些服务器下面实现类似的效果，将是一个多么爽的事。个人在近几天将对weblogic服务器下面的部署应用进行类似的研究

    我们做java开发的一般都会遇到如何保护我们开发的代码问题。java语言由于是基于jvm上面，所以反编译class文件很很容易。假如我们做了一个web程序，并把这个web程序发布给客户。实际上，客户是很容易反编译出我们的源代码出来，包括所有的src文件和jsp文件等等。

   那么，如何保护我们的源代码，实际上，应该有几种方法可以使用：1、使用代码混淆器  2、重载应用服务器的classloader

   对于第一种方法来说，现在外面有很多开源工具可以使用，个人认为最好用的当属proguard莫属。proguard主要是易用易学。而且提供的功能也挺多。下面是个人一点使用心得

   （1）、从网上download proguard工具，proguard工具主要包含是几个jar文件和一些example，下载地址http://proguard.sourceforge.net/

   （2）、将里面的几个jar文件添加到类路径下面。当然，也可以不添加，但是下面在做混淆的时候，必须指定classpath，使在做混淆的过程中，能否访问该类

   （3）、编写一个配置文件，主要是混淆器的一些参数。比如，下面是一个例子
-injars       platform.jar
-outjars      platform_out.jar
-libraryjars  <java.home>/lib/rt.jar
-libraryjars ibatis-common-2.jar
-libraryjars ibatis-dao-2.jar
-libraryjars ibatis-sqlmap-2.jar
-libraryjars junit-3.8.1.jar
-libraryjars d:/j2ee.jar
-libraryjars struts.jar
-libraryjars commons-lang.jar
-libraryjars D:/0working/coreproject/byislib/jasperreports-0.6.1.jar
-libraryjars  commons-beanutils.jar

-printmapping proguard.map
-overloadaggressively
-defaultpackage ''
-allowaccessmodification
-dontoptimize

-keep public class *
{
 public protected *;
}

-keep public class org.**

-keep public class it.**

各个参数的含义参考proguard文档，该文档非常详细，上手很容易

OK，到此就完成了代码混淆，打开产生的jar包可以看到，多了好多a、b、c之类的类文件。说明混淆结果已经成功。将原jar删除、运行产生的混淆jar包，一切正常！

常见问题：使用过程中个人遇到了几个问题，开始也是找了很久才解决
   a. 内存溢出异常： 主要是proguard在做混淆的时候，吃了很多内存，因此，在运行混淆器的时候，可以增加内存，比如 java -mx512m .....
  b.栈溢出异常： 主要是proguard在做混淆的时候，会对一些代码进行优化，若遇到一些相对复杂的方法时，可能会抛出此异常。对付的办法是增加配置参数-dontoptimize，如上面的配置例子所示

对于第二种方法，重载服务器的classloader的原理是这样。 首先我们通过一定算法把class文件加密； 然后写我们自己的classloader，替换服务器的classloader。 这样，我们可以读取class文件，通过我们自己的算法反加密成正确的class，然后再次进行load。这个方式还没应用起来，这几天个人正在研究，有什么新成果会在此做一些总结。

终于在blogjava开通了个人blog，真是开心
其实很早以前就想来这里开通一个，只是一直忙于项目中，没什么工夫过来。平时在项目中，或多或少总是会有很多心得，有时候没记下来，过一阵时间可能会忘光光，所以很想有个blog，记录这些闪光点。

最近在研究spring源代码，以后有什么心得会写出来