以下为本次代码分析工具FORTIFY对代码的分析结果。这些问题虽然古老、简单然而经典，也是需要引起重视。

代码问题主要集中在如下类别：存在安全隐患、存在资源泄漏隐患、序列化问题、字符串比较、异常处理问题，以及其它一些BAD PRACTICE和粗心引起的问题。

1.J2EE Bad Practices: Non-Serializable Object Stored in Session (Time and State, Structural)

把一个不可序列化的对象作为 HttpSession 属性来储存会破坏应用程序的可靠性。

代码示例

SharerInfo sharerInfo = new SharerInfo();

getServletRequest().getSession().setAttribute( “sharerInfo”, shareInfo);

其中SharerInfo类没有实现序列化(implements java.io.Serializable)

分析

对于不需要将对象序列化到同一jvm以外的应用场景，以上代码没有问题。然而考虑到系统的扩展性，以上问题应该予以避免。

以下是一些常见的会导致问题的场景：

1.       将session对象存储到外部系统

在一些大型应用系统的实现里，会考虑将部分SESSION里的对象钝化到数据库、磁盘里。

2.       集群环境

在非session-sticky的集群环境里，应用服务器会在集群里广播、复制session数据

修正

   ShareInfo类应该实现序列化：implements java.io.Serializable

2.Unreleased Resource

程序可能无法成功释放某一项系统资源

代码示例

         Try {

Connection con = jdbcTemplate.getDataSource().getConnection();

     }

         Catch(Exception e) {

   // Handle exception

}

Con.close();

分析

   系统资源比如数据库资源(Connection ,Statement，etc)，IO资源（InputStream,OutputStream,etc）都是有限的，如果没有正确的释放掉，就会出现资源泄漏的问题。常见的后果如出现数据库连接池无可用连接（pool exhausted），Too many open files等

 修正

  将资源释放代码放到finally块中进行

3. Mutable static field

将业务上不可变的静态值作为非final属性直接暴露给调用者

代码示例

public static  String  REALM;

static {

         REALM= bundle.getMessage("realm",null,DEFAULT_LOCALE);  

}

分析

  在业务上REALM是常量。但这样直接将REAM作为非FINAL静态属性暴露给调用者，容易导致静态属性值被修外部调用者修改，从而导致系统问题。

修正

  将 realm定义为final类型或者通过getRealm方法暴露接口，而隐藏setRealm方法。