首先，先说明的是，OneCoder采用的是使用vs2010的编译方式，zeromq的版本是3.2.4。

先编译zeromq3.2.4的源码。双击builds/msvc/ 目录下的msvc.sln导入到VS2010。选择x64位编译器，生成解决方案。

默认的生成目录是在zeromq-3.2.4\builds\msvc\Release\ 下。

然后编译Jzmq，从github上下载源码。
git clone https://github.com/zeromq/jzmq.git

默认master分支的代码在windows好像目录结构不对，所以这里选择的是切换到tag2.2.2的分支。
同样，打开jzmq目录下，builds\msvs\msvc.sln文件，导入到VS2010中。
编辑工程属性。选择x64编译环境。编辑VC++工程目录

在包含目录中，添加JDK的include目录，JDK include目录中的win32目录以及刚才zeromq目录中的include目录。

在库目录中，添加刚才编译zeromq生成的release目录。

然后生成解决方案即可。

与4.0.3版本编译，会出现异常：

error C2371: “int8_t”: 重定义；不同的基类型

可能兼容性还有问题。

运行期，只需要依赖编译生成的jzmq.dll和libzmq.dll文件即可。

ZeroMQ是什么可以自己去官网了解。
http://zeromq.org/

Mac下，对于安装了brew的朋友，很简单了。
首先安装zeromq

brew install zeromq

如果报错，很可能是因为没有安装命令行编译工具。可以通过xcode命令安装

xcode-select --install

安装成功后，即可正常编译zeromq了。

对于自己手动编译的朋友，也不麻烦。首先还是要保证安装了命令行编译工具，同上通过xcode-select安装。然后解压zeromq。然后进入目录，执行：

./configure
make
make install

然后安装jzmq，java binding
通过github下载源码
git clone https://github.com/zeromq/jzmq.git
然后依次执行

./autogen.sh
./configure
make
make install

即可在/usr/local/share/java 目录下编译出zmq.jar。

注：
如果报错：
checking whether the C compiler works… no
可以执行：

export CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
CPP='/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -E'

OneCoder在Restlet 2.1.4中 匪夷所思的ObjectRepresentation的构造函数中，提到过在使用2.1.4的时候遇到的异常

Exception in thread "main" java.lang.IllegalArgumentException : The serialized representation must have this media type: application/x-java-serialized-object or this one: application/x-java-serialized-object+xml
          at org.restlet.representation.ObjectRepresentation.<init>(ObjectRepresentation.java:203)
     at org.restlet.representation.ObjectRepresentation.<init>(ObjectRepresentation.java:114)

当时结果阅读代码，认为是Restlet的一个bug，并提交给Restlet。得到回复确认，称将在2.1.6版本中修复：

Hello,

thansk a lot for reporting this issue which is clearly a regression. I've added a ticket for that point: https://github.com/restlet/restlet-framework-java/issues/809
The fix will be part of the 2.1.6 release, available in a few minutes.

Best regards,
Thierry Boileau
 

今天想起，登录了一下Restlet的官方，发现最新版已经是2.1.6了。查看了一些change log，发现该问题确实已经解决。

===========
Changes log  
===========

- 2.1.6 (12/05/2013)
    - Bug fixed
       - Fixed issue #809 regression introduced when handling issues #774 and #778.

不过OneCoder还没有升级测试。大家可以测试一下。

 

使用Restlet进行同步请求，有时可能处理的时间会很长所以需要客户端进行较长时间的等待。从API中查得客户端的设置方式如下：

看到Spring Framework4.0发布的消息，看了下new future，OneCoder很喜欢spring这种追“时髦”的风格，groovy脚本配置和Java8都支持了。顺便就翻译了一下官方的迁移指南。对一般使用来说，迁移没什么难度。替换依赖基本就可以了。

如果想要了解Sping Framework4.0.0的新特性，可以参考官方文档中的：New Features and Enhancements in Spring Framework 4.0

环境依赖要求：

Spring Framework4.0 需要Java SE 6 或以上的版本。（特别强调，最低版本实际为2008年发布的JDK6 update 10）。如果你从老版本的Java环境中迁移，你至少需要升级到最近的JDK6版本。推荐使用Java7和8，Java8 的稳定开发者预览状态会一致持续到2014年3月，OpenJDK8 进入最终版为止。

如果你在 Java EE 服务器部署Spring应用，你需要确认你的应用支持Java EE 6及以上的版本。这其中，特别需要注意的是满足JPA2.0和Servlet3.0规范。这个意思其实是说，你仍然可以把你的Spring Framework4.0的应用部署在只支持Servlet2.5规范的容器中。（如。Google App Engine, WebSphere 7, WebLogic 10.3），只是Spring4中一些基于Servlet3.0的特性将会无效。

依赖升级

Spring Framework4.0 声明了下列(可选)依赖的最低版本:

规范

• Servlet 3.0 (2.5 支持部署)
• JPA 2.0
• Bean Validation 1.0
• JSF 2.0
• JCache 1.0 PFD
• JDO 3.0

容器

• Tomcat 6.0.30
• Jetty 7.3
• JBoss AS 6.0
• GlassFish 3.1
• Oracle WebLogic 10.3.4 (with JPA 2.0 patch applied)
• IBM WebSphere 7.0.0.9 (with JPA 2.0 feature pack installed)

库

• Hibernate Validator 4.3
• Hibernate 3.6 (推荐4.2 )
• EhCache 2.1 (推荐2.5)
• <Quartz 1.8 (推荐2.2 )
• Jackson 1.8 (推荐2.2 )
• Groovy 1.8 (推荐2.2)
• Joda-Time 2.0 (推荐2.3)</span>
• Hessian 4.0
• XStream 1.4
• Apache POI 3.5

废弃的代码

下列的类和方法在Spring Framework4.0中被废弃。这些代码未来将会被移除，所以请检查javadoc并迁移至推荐的写法：

Jackson v1

所有Jackson v1支持的被废弃，以支持Jacksonv2:

• MappingJacksonMessageConverter
• JacksonObjectMapperFactoryBean
• MappingJacksonHttpMessageConverter

泛型：

GenericTypeResolver中的许多方法都被废弃了。新的ResolvableType类提供了对GeneriTypeResolver和GenericCollectionTypeResolver类中废弃方法的替换：

• GenericTypeResolver.getTargetType(MethodParameter methodParam)
• GenericTypeResolver.resolveType(Type genericType, Map<TypeVariable, Type> map)
• GenericTypeResolver.getTypeVariableMap(Class<?> clazz)

Burlap

Burlap不再在开发包下，并且将在以后完全不再提供支持。

• BurlapClientInterceptor
• BurlapExporter
• BurlapProxyFactoryBean
• BurlapServiceExporter
• SimpleBurlapServiceExporter

过时的JBoss类

下面的类由于不在当前JBoss释放版中而被废弃：</span></p>

• JBossWorkManagerTaskExecutor
• JBossWorkManagerUtils

其他废弃

• AbstractJaxWsServiceExporter.setWebServiceFeatures(Object[] webServiceFeatures)
• JaxWsPortClientInterceptor.setWebServiceFeatures(Object[] webServiceFeatures)</span>
• DefaultKeyGenerator

默认的缓存key生成器</span>

Spring使用的默认的KeyGenerator实现，由原来的DefaultKeyGenerator变为SimpleKeyGenerator。新的生成器不会再有key冲突并且基本不太可能使一个缓存的方法返回错误的结果。如果仍想使用之前的key策略，你需要配置使用废弃的DefaultKeyGenerator或者创建一个自定义的KeyGenerator实现。

MVC 命名空间

Spring MVC的命名空间XSD已经升级，以正确使用一对属性。当升级到spring-mvc-4.0.xsd后，你应该分别用 enable-matrix-variables 和ignore-default-model-on-redirect respectively 来替换原来的enableMatrixVariables 和ignoreDefaultModelOnRedirect 属性。

虽然log4j2 目前还是beta版，不过OneCoder已经忍不住要尝试一下。跟使用log4j 比起来，上手上主要的区别有。
1、依赖的jar包。使用slf4j+log4j2 时，依赖的jar包如下：(gradle配置，Maven对照修改即可)

dependencies{
compile(
"org.apache.logging.log4j:log4j-api:$log4j_version",
"org.apache.logging.log4j:log4j-core:$log4j_version",
"org.apache.logging.log4j:log4j-slf4j-impl:$log4j_version"
)

}

其中，log4j_version=2.0-beta9

2、默认配置文件名字
默认搜索的配置文件名字变为log4j2或log4j-test开头的配置文件，这个变化，让OneCoder吃了些苦头。没注意观察，还自以为配置文件还是log4j.xml，结果怎么都不管用。后来仔细阅读官方文档才发现问题。log4j2中，支持json和xml两个格式的配置文件，配置文件的搜索顺序为：

  1. Log4j will inspect the "log4j.configurationFile" system property and, if set, will attempt to load the configuration using the ConfigurationFactory that matches the file extension.
  2. If no system property is set the JSON ConfigurationFactory will look for log4j2-test.json or log4j2-test.jsn in the classpath.
  3. If no such file is found the XML ConfigurationFactory will look for log4j2-test.xml in the classpath.
  4. If a test file cannot be located the JSON ConfigurationFactory will look for log4j2.json or log4j2.jsn on the classpath.
  5. If a JSON file cannot be located the XML ConfigurationFactory will try to locate log4j2.xml on the classpath.
  6. If no configuration file could be located the DefaultConfiguration will be used. This will cause logging output to go to the console.

环境变量log4j.configurationFile指定的文件->log4j2-test.json/log4j2-test.jsn -> log4j2-test.xml -> log4j2.json/log4j2.jsn -> log4j2.xml - > 默认配置DefaultConfiguration

3、配置文件格式

配置文件样例，跟1比起来有所简化。

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
     <Appenders>
          <Console name="Console" target="SYSTEM_OUT">
               <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss} [%t] %-5level %l - %msg%n" />
          </Console>
     </Appenders>
     <Loggers>
          <Root level="debug">
               <AppenderRef ref="Console" />
          </Root>
     </Loggers>
</Configuration>

其他的变化和优势，您可以在使用中慢慢体会了。

OneCoder验证用Restlet做服务，读取远端文件内容功能，编写验证代码。目前测试通过，主要是利用restlet内部提供的InputRepresentation对象，通过ReadableByteChannel，按字节流的方式读取文件内容。代码如下，省略注册服务的部分，只给出服务端和客户端关键代码：
服务端：

package com.coderli.restlet.file;

import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.InputStream;


import org.restlet.representation.InputRepresentation;
import org.restlet.resource.Get;
import org.restlet.resource.ServerResource;


/**
* 文件读取服务端
*
* @author lihzh(OneCoder)
* @date 2013年12月4日 下午4:35:22
* @website http://www.coderli.com
*/
public class MacFile extends ServerResource {


     @Get
     public InputRepresentation readFile() throws FileNotFoundException {
          System. out.println("开始读取文件" );
          File file = new File("/Users/apple/Documents/stockdata/SH600177.TXT" );
          InputStream inputStream = new FileInputStream(file);
          InputRepresentation inputRepresentation = new InputRepresentation(
                   inputStream);
           return inputRepresentation;
     }
}

客户端：

package com.coderli.restlet.file;

import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.channels.ReadableByteChannel;


import org.restlet.data.MediaType;
import org.restlet.representation.ReadableRepresentation;
import org.restlet.representation.Representation;
import org.restlet.resource.ClientResource;


/**
* 文件读取，客户端
*
* @author lihzh(OneCoder)
* @date 2013年12月4日 下午4:36:00
*/
public class MacFileClient {


     public static void main(String[] args) throws IOException {
          ClientResource clientResource = new ClientResource(
                    "http://localhost:8182/macFile" );
          Representation rp = clientResource.get(MediaType.ALL );
          ReadableRepresentation rRepresentation = (ReadableRepresentation) rp;
          ReadableByteChannel rbc = rRepresentation.getChannel();
          ByteBuffer bb = ByteBuffer. allocate(1024);
           int index = -1;
           do {
              index = rbc.read(bb);
               if (index <= 0) {
                    break;
              }
              bb.position(0);
               byte[] bytes = new byte[index];
              bb.get(bytes);
              System. out.print(new String(bytes, "gbk"));
              bb.clear();
          } while (index > 0);
     }
}

需要注意的是，这里客户端实现中的System.out.print部分是由缺陷的，在有汉字的时候，会因为不正确的截断字节数组造成乱码。这里是因为我验证的时候文件只有英文和数组，所以简单的采用此种方式。

OneCoder使用Restlet最新版2.1.4开发样例，却一直抛出异常：

Exception in thread “main” java.lang.IllegalArgumentException : The serialized representation must have this media type: application/x-java-serialized-object or this one: application/x-java-serialized-object+xml
          at org.restlet.representation.ObjectRepresentation.(ObjectRepresentation.java:203)
     at org.restlet.representation.Objec tRepresentation.(ObjectRepresentation.java:114)

日志是项目中必用的东西，日志产品里最普及应该就是log4j了。(logback这里暂不讨论。) 先看一下常用的log4j的用法，一般来说log4j都会配合slf4j或者common-logging使用，这里已slf4j为例。添加gradle依赖：

dependencies {
compile('log4j:log4j:1.2.17',
'org.slf4j:slf4j-api:1.7.5',
'org.slf4j:slf4j-log4j12:1.7.5')
}

最直接的用法就是在每个需要记录日志的类里，构造一个属于自己类的log实例，实际上很多著名的开源项目也是这么做的。如spring。

private static final Log logger = LogFactory.getLog(BeanUtils.class);

那么我们也先从这种用法开始，先配置好最基本的log4j.xml配置文件。

<?xml version= "1.0" encoding ="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "http://log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" >

     <appender name="Console" class="org.apache.log4j.ConsoleAppender" >
           <layout class= "org.apache.log4j.PatternLayout" >
               <param name= "ConversionPattern" value ="%d >> %-5p >> %t >> %l >> %m%n" />
           </layout>
     </appender >
     <root >
           <level value= "info" />
           <appender-ref ref= "Console" />
     </root >

</log4j:configuration>

参数说明：

%p 输出优先级，即DEBUG，INFO，WARN，ERROR，FATAL
%r 输出自应用启动到输出该log信息耗费的毫秒数
%c 输出所属的类目，通常就是所在类的全名
%t 输出产生该日志事件的线程名
%n 输出一个回车换行符，Windows平台为“\r\n”，Unix平台为“\n”
%d 输出日志时间点的日期或时间，默认格式为ISO8601，也可以在其后指定格式，比如：%d{yyy MMM dd HH:mm:ss,SSS}，输出类似：2002年10月18日 22：10：28，921
%l 输出日志事件的发生位置，包括类目名、发生的线程，以及在代码中的行数。

日志测试类：

package com.coderli.log4jpackage;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
/**
* log4j封装实验室中的用户模拟类
*
* @author OneCoder
* @date 2013年11月25日 下午4:39:19
*/
public class UserClass {

     private static final Logger logger = LoggerFactory
              . getLogger(UserClass.class);
     public static void main(String[] args) {
           logger.info("这是一个Info级别的log4j日志。" );
     }
}

输出日志：

2013-11-26 11:09:21,305 >> INFO  >> main >> com.coderli.log4jpackage.UserClass.main(UserClass.java:18) >> 这是一个Info级别的log4j日志。

这里包含的日志发生时的类、线程、行号等信息。很完整。本身这么做没什么问题，只是可能有的项目考虑如果每个类里都写这样一个开头，有点麻烦，同时，如果每个类一个独立的声明，log4j内存会缓存很多的实例，占用内存，可能有时候也不便于统一配置管理。所以，有些项目里考虑了对log进行封装，提供统一的一个静态方法调用：

package com.coderli.log4jpackage;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
* @author lihzh(OneCoder)
* @date 2013年11月25日 下午4:39:54
* @blog http://www.coderli.com
*/
public class MyLog4j {
     private static final Logger logger = LoggerFactory.getLogger("MyLog4j");

     public static void info(String msg) {
           logger.info(msg);
     }
}

记录日志代码变为：

/**
 * log4j封装实验室中的用户模拟类
 *
 * @author OneCoder
 * @date 2013年11月25日 下午4:39:19
 */
public class UserClass {

     public static void main(String[] args) {
          MyLog4j. info("这是一个Info级别的log4j日志。" );
     }
}

日志输出：

2013-11-26 11:23:29,936 >> INFO  >> main >> com.coderli.log4jpackage.MyLog4j.info(MyLog4j.java:16 ) >> 这是一个Info级别的log4j日志。

咋一看没什么问题，仔细分析就发现，对我们调试很有帮助的日志发生时的类名、行号都编程了封装类里面的类和行，这对于依靠日志进行错误调试来说是悲剧的。这种封装虽然解决了实例过多的问题，但是也是失败的，甚至是灾难性的。

也有人把发生日志的Class信息也传递进来一起打印。如：

public static void info(String className, String msg) {
           logger.info(className + ">> " + msg);
     }

这种方式显然是治标不治本的。于是很多人想到了另外的封装方式，即提供一个统一获取logger实例的位置，然后在自己的类里进行嗲用：

public static Logger getLogger() {
           return logger;
     }

调用代码：

public static void main(String[] args) {
          MyLog4j. getLogger().info("这是一个Info级别的log4j日志。" );
     }

这种方法，日志虽然恢复了正常，但是对于开发者实际又增加了麻烦，打印一个日志需要两部操作了。当然你可以使用import static。或者每个类里还是全局声明一个logger实例。

那么有没有想过，slf4j内部是怎么对log4j封装的呢？我们通过slf4j调用为什么就可以之间获得你实际打印日志的行号，同时又不会把自己类给暴露出来呢？你可能还没明白我在说什么，细说一下，如果我们直接使用log4j的logger，打印出来的是我们调用类的行号这没什么问题，但是这里我们获得的是slf4j的logger实例，它底层调用的是log4j的logger实例，那么为什么不会打印出slf4j内部调用类的行号呢？这就是我关心的问题。知道了这个，也许我们就可以封装出更好用的全局log组件了。

其实，这个问题的关键就集中在log4j是如何获取你调用日志的代码的类和行号的，在Java中可以通过Throwable来获取调用堆栈, 例如我们将如下代码，放在MyLog4j类的info方法中：

   public static void info(String msg) {
      Throwable throwable = new Throwable();
      StackTraceElement[] ste = throwable.getStackTrace();
      for (StackTraceElement stackTraceElement : ste) {
         System.out
               .println("ClassName: " + stackTraceElement.getClassName());
         System.out.println("Method Name: "
               + stackTraceElement.getMethodName());
         System.out.println("Line number: "
               + stackTraceElement.getLineNumber());
      }
      logger.info(msg);
   }

再次通过UserClass调用，就可获得如下输出：

ClassName: com.coderli.log4jpackage.MyLog4j
Method Name: info
Line number: 28
ClassName: com.coderli.log4jpackage.UserClass
Method Name: main
Line number: 12

由此可见只要在调用堆栈里找到用户的类，就可以获得所有我们需要的信息。有了这个基础，我们再来看看slf4j和log4j是怎么做的。

在log4j的Logger中，实际对外提供了用于封装的统一的log方法。

 /**

     This is the most generic printing method. It is intended to be
     invoked by <b>wrapper</b> classes.

     @param callerFQCN The wrapper class' fully qualified class name.
     @param level The level of the logging request.
     @param message The message of the logging request.
     @param t The throwable of the logging request, may be null.  */
  public
  void log(String callerFQCN, Priority level, Object message, Throwable t）

而第一个参数callerFQCN，就是关键的决定调用者位置的参数。在LocationInfo中，可看到对该参数的使用方式为：

public LocationInfo(Throwable t, String fqnOfCallingClass) {
      if(t == null || fqnOfCallingClass == null)
return;
      if (getLineNumberMethod != null) {
          try {
              Object[] noArgs = null;
              Object[] elements =  (Object[]) getStackTraceMethod.invoke(t, noArgs);
              String prevClass = NA;
              for(int i = elements.length - 1; i >= 0; i--) {
                  String thisClass = (String) getClassNameMethod.invoke(elements[i], noArgs);
                  if(fqnOfCallingClass.equals(thisClass)) {
                      int caller = i + 1;
                      if (caller < elements.length) {
                          className = prevClass;
                          methodName = (String) getMethodNameMethod.invoke(elements[caller], noArgs);
                          fileName = (String) getFileNameMethod.invoke(elements[caller], noArgs);
                          if (fileName == null) {
                              fileName = NA;
                          }
                          int line = ((Integer) getLineNumberMethod.invoke(elements[caller], noArgs)).intValue();
                          if (line < 0) {
                              lineNumber = NA;
                          } else {
                              lineNumber = String.valueOf(line);
                          }
                          StringBuffer buf = new StringBuffer();
                          buf.append(className);
                          buf.append(".");
                          buf.append(methodName);
                          buf.append("(");
                          buf.append(fileName);
                          buf.append(":");
                          buf.append(lineNumber);
                          buf.append(")");
                          this.fullInfo = buf.toString();
                      }
                      return;
                  }
                  prevClass = thisClass;
              }
              return;
…….//省略若干

可见，log4j把传递进来的callerFQCN在堆栈中一一比较，相等后，再往上一层即认为是用户的调用类。所以，在slf4j封装的logger中是这样封装的：

final static String FQCN = Log4jLoggerAdapter.class .getName();
public void info(String msg) {
    logger.log(FQCN, Level. INFO, msg, null );
  }

用户的代码调用的正是调用的这个info，所以就会正常的显示用户代码的行号了。那么对于封装来说，你只需要注意调用log4j的log方法，并传递进去正确的FQCN即可。

final static String FQCN = Log4jLoggerAdapter.class .getName();
public void info(String msg) {
    logger.log(FQCN, Level. INFO, msg, null );
  }

还是OneCoder在项目中沙箱的问题，用classloader隔离做的沙箱，反复运行用户的任务，出现永生区内存溢出：
java.lang.OutOfMemoryError: PermGen space

这个问题在tomcat重复热部署的时候其实比较常见。其道理也和我们沙箱的道理基本一致，就是每次任务运行的类没有卸载掉。而永生区正式存储加载入classloader中的类，反射的方法等的地方。如此只增不减，自然会产生溢出。

那么，什么情况下会产生沙箱中loader进来的类不会被回收的情况呢？简单说，就是当外部loader里加载的类，持有了沙箱loader中的加载的类的实例时。道理简单，但是实际项目中，寻找这种可能情况就复杂的多了。为了说明这个道理，我们做个简单的试验。

ClassLoader加载试验

试验思想，基本思想就是循环创建Classloader手动加载包，并通过反射调用包中的代码，考察在外部loader有无引用的情况下，PermGen区的变化情况。监控工具，即为JDK自带的Java VisualVM。

场景一、无引用

package com.coderli.permgen.leak;

import java.io.File;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.SynchronousQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

/**
 * Classloader导致Permleak测试类
 * 
 * @author <a href="http://www.coderli.com">OneCoder</a>
 * @date 2013年11月21日 上午10:07:02
 * @website http://www.coderli.com
 */
public class ClassloaderPermGenLeakTest {

public static void main(String[] args) throws InterruptedException,
MalformedURLException, ClassNotFoundException {

     ExecutorService es = new ThreadPoolExecutor(1, 10, 5L,
     TimeUnit.SECONDS, new SynchronousQueue<Runnable>());
     ClassloaderPermGenLeakTest clpg = new ClassloaderPermGenLeakTest();

     for (int i = 0; i < 1; i++) {
          es.execute(clpg.new ExecutroRun());
     }
     Thread.sleep(2000000);
}

private class ExecutroRun implements Runnable {

@Override
public void run() {
     try {
          permLeak();
     } catch (Exception e) {
          e.printStackTrace();
     }
}

private void permLeak() throws Exception {
     Thread.sleep(5000);
     List<Object> insList = new ArrayList<Object>();
     ClassLoader _temp = Thread.currentThread().getContextClassLoader();
     for (int i = 0; i < 100; i++) {
          URL[] urls = getURLS();
          URLClassLoader urlClassloader = new URLClassLoader(urls, null);
          Class<?> logfClass = Class.forName("org.apache.commons.logging.LogFactory", true,
                urlClassloader);
          Method getLog = logfClass.getMethod("getLog", String.class);
          getLog.invoke(logfClass, "logName&rdquo;);        (100);
          System.out.println("print: " + i);
     }
}

private URL[] getURLS() throws MalformedURLException {
     File libDir = new File("src/main/java/com/coderli/permgen/leak/lib");
     File[] subFiles = libDir.listFiles();
     int count = subFiles.length;
     URL[] urls = new URL[count];
     for (int i = 0; i < count; i++) {
          urls[i] = subFiles[i].toURI().toURL();
     }
     return urls;
     }
}

从代码可见，在自定义的100个Classloader里，我们只是通过反射调用了LogFactory里的getLog方法，对于该方法返回的实例，并没有保存。所以没有引用，可正常回收。

通过内存dump查看，可以发现，内存中没有commmon logging相关的类，说明PermGen区正常回收了。

场景二、持有引用

修改代码如下：

package com.coderli.permgen.leak;

import java.io.File;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.SynchronousQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

/**
 * Classloader导致Permleak测试类
 * 
 * @author lihzh
 * @date 2013年11月21日 上午10:07:02
 */
public class ClassloaderPermGenLeakTest {


private List<Object> insList = new ArrayList<Object>();

public static void main(String[] args) throws InterruptedException,
MalformedURLException, ClassNotFoundException {

     ExecutorService es = new ThreadPoolExecutor(1, 10, 5L,
     TimeUnit.SECONDS, new SynchronousQueue<Runnable>());
     ClassloaderPermGenLeakTest clpg = new ClassloaderPermGenLeakTest();

     for (int i = 0; i < 1; i++) {
          es.execute(clpg.new ExecutroRun());
     }
     Thread.sleep(2000000);
     System.out.println(clpg.insList.size());
}

private class ExecutroRun implements Runnable {

     @Override
     public void run() {
          try {
               permLeak();
          } catch (Exception e) {
               e.printStackTrace();
          }
     }

private void permLeak() throws Exception {
     Thread.sleep(5000);
     for (int i = 0; i < 100; i++) {
          URL[] urls = getURLS();
          URLClassLoader urlClassloader = new URLClassLoader(urls, null);
          Class<?> logfClass = Class.forName(
               "org.apache.commons.logging.LogFactory", true,
               urlClassloader);
          Method getLog = logfClass.getMethod("getLog", String.class);
          Object result = getLog.invoke(logfClass, "logName");
          insList.add(result);
          System.out.println("print: " + i);
     }
}

private URL[] getURLS() throws MalformedURLException {
     File libDir = new File("src/main/java/com/coderli/permgen/leak/lib");
     File[] subFiles = libDir.listFiles();
     int count = subFiles.length;
     URL[] urls = new URL[count];
     for (int i = 0; i < count; i++) {
          urls[i] = subFiles[i].toURI().toURL();
     }
     return urls;
     }
}

在外部增加一个list存放内部反射出来的对象，并保证list对象被引用。

这次可看到PermGen不会被释放，观察dump内存

有大量的commons logging类没有释放。即出现内存泄漏。

这是最简单，最直观的PermGen Leak的场景。更多的时候，这种内存泄漏并不是那么的好察觉。 比如，我们经历的沙盒中的问题就是一个比较典型的问题，沙盒中使用log4j。

log4j导致永生区溢出的问题其实并不罕见，网上也有不少人讨论过这个问题。下面摘录的一段博文内容，给了我启示。

More sneaky problems

I don't blame you if you didn't see the problem with the Level class: it's sneaky. Last year we had some undeployment problems in our application server. My team, in particular Edward Chou, spent some time to track them all down. Next to the problem withLevel, here are some other problems Edward and I encountered. For instance, if you happen to use some of the Apache Commons BeanHelper's code: there's a static cache in that code that refers to Method objects. The Method object holds a reference to the class the Method points to. Not a problem if the Apache Commons code is loaded in your application's classloader. However, you do have a problem if this code is also present in the classpath of the application server because those classes take precedence. As a result now you have references to classes in your application from the application server's classloader... a classloader leak!

I did not mentiond yet the simplest recipe for disaster: a thread started by the application while the thread does not exit after the application is underplayed.

在使用log4j的时候，不论你是直接使用log4j还是通过slf4j和commons-longging间接使用，当你通过LoggerFactory(LogFactory)获取一个实例的时候，log4j都会将该实例缓存起来。这就会导致你外部持有了一个沙箱内部的log对象，内部又持有了一个外部的对象，最终导致所有加载的log4j的相关类都无法释放。产生溢出。

而在我们的项目还不仅如此，我们还是使用了log4j的MDC类，log4j提供了线程相关的MDC类用于保存当前线程的日志上线文信息。如果内外loader的类公用一个线程，那么在线程没有终止的情况下，MDC信息会绑定在当前线程的ThreadLocal上，这也会造成类无法释放，最终产生溢出。

那么解决上述问题的比较常见的办法就是全局使用一份log4j，即将log4j置于更高层次的loader中进行加载，避免每个loader重复加载。而在我们的项目中，也采用了类似的做法，即在沙箱的一个公用的父类loader中加载了log4j类。从而避免溢出。

最后，推荐两篇相关博文，里面有关于永生区(PermGen)较为细致的分析和讲解

http://frankkieviet.blogspot.com/2006/10/classloader-leaks-dreaded-permgen-space.html

https://blogs.oracle.com/jonthecollector/entry/presenting_the_permanent_generation