String.equals()方法比较的是字符串的内容,使用equals(...)方法会对字符串中的所有字符一个接一个地进行比较,如果完全相等那么返回true。 在这种情况下全部字符串都是相同的,所以当字符串s0 与s1 或s2 比较时我们得到的返回值均为true 。运算符“==”比较的是String 实例的引用。在这种情况下很明显s0 和s1 并不是同一个String 实例,但s0 和s2 是同一个。读者也许会问s0 和s2 怎么是同一个对象呢？
      这个问题的答案来自于Java语言规范中关于字符串常量String Literals 的章节。本例中“Programming” ,“Program”和“ming”都是字符串常量!!它们在编译期就被确定了当一个字符串由多个字符串常量连接而成时,例如s2 ,它同样在编译期就被确定为一个字符串常量。Java 确保一个字符串常量只有一份拷贝,所以当Programming”和“Program”+“ming”被确定为值相等时,Java 会设置两个变量的引用为同一个常量的引用。在常量池constant pool 中,Java 会跟踪所有的字符串常量。
       常量池指的是在编译期被确定,并被保存在已编译的.class 文件中的一些数据。它包含了关于方法,类,接口等等,当然还有字符串常量的信息。当JVM 装载了这个.class 文件。变量s0 和s2 被确定,JVM 执行了一项名为常量池解析constant pool resolution 的操作。该项操作针对字符串的处理过程包括下列3 个步骤,摘自JVM 规范5。4 节::
       ¹ 如果另一个常量池入口constant pool entry 被标记为CONSTANT_String2 ,并且指出同样的Unicode 字符序列已经被确定,那么这项操作的结果就是为之前的常量
池入口创建的String 实例的引用。
       ² 否则,如果intern()方法已经被这个常量池描述的一个包含同样Unicode 字符序列的String 实例调用过了,那么这项操作的结果就是那个相同String 实例的引用。
      ³ 否则,一个新的String 实例会被创建它包含了CONSTANT_String 入口描述的Unicode 字符;序列这个String 实例就是该项操作的结果。
      也就是说,当常量池第一次确定一个字符串,在Java 内存栈中就创建一个String 实例。在常量池中,后来的所有针对同样字符串内容的引用,都会得到之前创建的String 实例。当JVM 处理到第6 行时,它创建了字符串常量Programming 的一份拷贝到另一个String 实例中。所以对s0 和s1 的引用的比较结果是false ,因为它们不是同一个对象。这就是为何s0==s1 的操作在某些情况下与s0.equals(s1)不同。s0==s1 比较的是对象引用的值;而s0.equals(s1)实际上执行的是字符串内容的比较。
      存在于.class 文件中的常量池,在运行期被JVM 装载,并且可以扩充。此前提到的intern()方法针对String 实例的这个意图提供服务。当针对一个String 实例调用了intern()方法,intern()方法遵守前面概括的第3 步以外的常量池解析规则:因为实例已经存在,而不需要另外创建一个新的。所以已存在的实例的引用被加入到该常量池。来看看另一个例子:
01: import java.io.*;
02:
03: public class StringExample2
04: {
05: public static void main (String args[])
06:{
07: String sFileName = "test.txt";
08: String s0 = readStringFromFile(sFileName);
09: String s1 = readStringFromFile(sFileName);
10:
11: System.out.println("s0 == s1: " + (s0 == s1));
12: System.out.println("s0.equals(s1): " + (s0.equals(s1)));
13:
14: s0.intern();
15: s1.intern();
16:
17: System.out.println("s0 == s1: " + (s0 == s1));
18: System.out.println("s0 == s1.intern(): " +
19: (s0 == s1.intern()));
20: }
21:
22: private static String readStringFromFile (String sFileName)
23: {
24: //…read string from file…
25: }
26: }
     这个例子没有设置s0 和s1 的值为字符串常量,取而代之的是在运行期它从一个文件中读取字符串,并把值分配给readStringFromFile(...)方法创建的String 实例。从第9 行开始,程序对两个被新创建为具有同样字符值的String 实例进行处理。当你看到从第11 行到12 行的输出结果时,你会再次注意到这两个对象并不是同一个,但它们的内容是相同的。输出结果如下:

s0 == s1: false
s0.equals(s1): true
s0 == s1: false
s0 == s1.intern(): true
第14 行所做的是将String 实例的引用s0 存入常量池。当第15 行被处理时,对s1.intern()方法的调用,会简单地返回引用s0。 这样一来第17 行和18 行的输出结果正是我们所期望的,s0 与s1 仍旧是截然不同的两个String 。实例因此s0==s1 的结果是false。 而s1.intern()返回的是常量池中的引用值即s0 所,以表达式s0==s1.intern()的结果是true。 假如我们希望将实例s1 存入常量池中,我们必须首先设置s0 为null, 然后请求垃圾回收器garbagecollector 回收被指向s0 的String 实例。在s0 被回收后s1.intern()方法的调用,将会把s1存入常量池。
       总的来说在执行等式比较时,应该始终使用String.equals(...)方法,而不是==运算符。如果你还是习惯性地使用==运算符,那么intern()方法可以帮助你得到正确的答案。因为当n 和m 均为String 实例的引用时,语句n.equals(m)与n.intern() ==m.intern()得到的结果是一致的。假如你打算充分利用常量池的优势那么你就应该选择String.intern()方法。

For use as a base class:

• Override getConnection() to pass any connection you want. Typically this is used to enable application wide connection pooling.
• Override closeConnection(Connection con) -- if you override getConnection make sure to implement closeConnection to handle the connection you generated. Typically this would return the connection to the pool it came from.
• Override getLogStatement(LoggingEvent event) to produce specialized or dynamic statements. The default uses the sql option value.

原来log4j建议我们把其提供的JDBCAppender作为基类来使用，然后Override三个父类的方法：getConnection(),closeConnection(Connection con)和getLogStatement(LoggingEvent event)。
原来如此，那就写一个子类JDBCPoolAppender来替代这个JDBCAppender
JDBCPoolAppender代码和其相关代码如下：

JDBCPoolAppender.java:

package common.log;
import java.sql.Connection;
import org.apache.log4j.spi.LoggingEvent;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.Iterator;
import org.apache.log4j.spi.ErrorCode;
import org.apache.log4j.PatternLayout;
import common.sql.MyDB;
import common.sql.GeneralDb;

public class JDBCPoolAppender extends org.apache.log4j.jdbc.JDBCAppender {
   
    private MyDB mydb = null;  
    protected String sqlname=""; //增加一个数据库jndiName的属性
    protected Connection connection = null;
    protected String sqlStatement = "";
    /**
     * size of LoggingEvent buffer before writting to the database.
     * Default is 1.
     */
    protected int bufferSize = 1;

    public JDBCPoolAppender() {
        super();
    }

    /**
     * ArrayList holding the buffer of Logging Events.
     */
    public void append(LoggingEvent event) {
        buffer.add(event);
        if (buffer.size() >= bufferSize)
            flushBuffer();
    }

    /**
     * By default getLogStatement sends the event to the required Layout object.
     * The layout will format the given pattern into a workable SQL string.
     *
     * Overriding this provides direct access to the LoggingEvent
     * when constructing the logging statement.
     *
     */
    protected String getLogStatement(LoggingEvent event) {
        return getLayout().format(event);
    }

    /**
     *
     * Override this to provide an alertnate method of getting
     * connections (such as caching).  One method to fix this is to open
     * connections at the start of flushBuffer() and close them at the
     * end.  I use a connection pool outside of JDBCAppender which is
     * accessed in an override of this method.
     * */
    protected void execute(String sql) throws SQLException {
        Connection con = null;
        Statement stmt = null;
        try {
            con = getConnection();
            stmt = con.createStatement();
            stmt.executeUpdate(sql);
        } catch (SQLException e) {
            if (stmt != null)
                stmt.close();
            throw e;
        }
        stmt.close();
        closeConnection(con);
        //System.out.println("Execute: " + sql);
    }

  
    public int getBufferSize() {
        return bufferSize;
    }
}

    public Connection getConnection() {
        return getNewConnection();
    }
}
GeneralDb.java:

package common.sql;

import java.util.*;

public class GeneralDb {
    private static Hashtable dbPool;
    public static MyDB getInstance(String dbname) {
        if (dbPool == null) {
            dbPool = new Hashtable();
        }
        MyDB db = (MyDB) dbPool.get(dbname);
        if (db == null) {
            db = new MyDB(dbname);
            dbPool.put(dbname, db);
        }
        return db;
    }
}

Log4j数据库连接池的配置如下：
log4j.appender.JDBC=common.log.JDBCPoolAppender
log4j.appender.JDBC.sqlname=log
log4j.appender.JDBC.layout=org.apache.log4j.PatternLayout
log4j.appender.JDBC.sql=INSERT INTO LOGGING (log_date, log_level, location, message) VALUES ('%d{ISO8601}', '%-5p', '%C,%L', '%m')


poolman.xml配置如下：

〈?xml version="1.0" encoding="UTF-8"?>
〈poolman>
  〈management-mode>local〈/management-mode>
  〈datasource>
    〈dbname>log〈/dbname>
    〈jndiName>log〈/jndiName>
    〈driver>com.mysql.jdbc.Driver〈/driver>
    〈url>jdbc:mysql://localhost:3306/test〈/url>
    〈username>use〈/username>
    〈password>password〈/password>
    〈minimumSize>0〈/minimumSize>
    〈maximumSize>10〈/maximumSize>
    〈logFile>logs/mysql.log〈/logFile>
  〈/datasource>

〈/poolman>
   

运行成功！对于JDBCPoolAppender的属性（比如sqlname属性）我们可以利用Log4j的反射机制随便添加，只要在配置文件给其附上值即可应用，而原来的父类里面的一些属性（username什么的)和其get,set方法由于在连接池中不需要，所以删除。而在JDBCPoolAppender类中，我也只是将getConnection 方法Override ，在这个方法中我们可以根据需要生成我们的Connection对象，另外两个方法大家可以根据需求来决定怎样Override。：）
            

 

java.compiler Name of JIT compiler to use
java.ext.dirs Path of extension directory or directories
os.name Operating system name
os.arch Operating system architecture
os.version Operating system version
file.separator File separator ("/" on UNIX) path.separator Path separator (":" on UNIX)
line.separator Line separator ("\n" on UNIX)
user.name User's account name
user.home User's home directory
user.dir User's current working directory

　　Java中文问题一直困扰着很多初学者，如果了解了Java系统的中文问题原理，我们就可以对中文问题能够采取根本的解决之道。

　　最古老的解决方案是使用String的字节码转换，这种方案问题是不方便，我们需要破坏对象封装性，进行字节码转换。

　　还有一种方式是对J2EE容器进行编码设置，如果J2EE应用系统脱离该容器，则会发生乱码，而且指定容器配置不符合J2EE应用和容器分离的原则。

　　在Java内部运算中，涉及到的所有字符串都会被转化为UTF-8编码来进行运算。那么，在被Java转化之前，字符串是什么样的字符集？ Java总是根据操作系统的默认编码字符集来决定字符串的初始编码，而且Java系统的输入和输出的都是采取操作系统的默认编码。

　　因此，如果能统一Java系统的输入、输出和操作系统3者的编码字符集合，将能够使Java系统正确处理和显示汉字。这是处理Java系统汉字的一个原则，但是在实际项目中，能够正确抓住和控制住Java系统的输入和输出部分是比较难的。J2EE中，由于涉及到外部浏览器和数据库等，所以中文问题乱码显得非常突出。

　　J2EE应用程序是运行在J2EE容器中。在这个系统中，输入途径有很多种：一种是通过页面表单打包成请求（request）发往服务器的；第二种是通过数据库读入；还有第3种输入比较复杂，JSP在第一次运行时总是被编译成Servlet，JSP中常常包含中文字符，那么编译使用javac时，Java将根据默认的操作系统编码作为初始编码。除非特别指定，如在Jbuilder/eclipse中可以指定默认的字符集。

　　输出途径也有几种：第一种是JSP页面的输出。由于JSP页面已经被编译成Servlet，那么在输出时，也将根据操作系统的默认编码来选择输出编码，除非指定输出编码方式；还有输出途径是数据库，将字符串输出到数据库。

　　由此看来，一个J2EE系统的输入输出是非常复杂，而且是动态变化的，而Java是跨平台运行的，在实际编译和运行中，都可能涉及到不同的操作系统，如果任由Java自由根据操作系统来决定输入输出的编码字符集，这将不可控制地出现乱码。

　　正是由于Java的跨平台特性，使得字符集问题必须由具体系统来统一解决，所以在一个Java应用系统中，解决中文乱码的根本办法是明确指定整个应用系统统一字符集。

　　指定统一字符集时，到底是指定ISO8859_1 、GBK还是UTF-8呢？

　　（1）如统一指定为ISO8859_1，因为目前大多数软件都是西方人编制的，他们默认的字符集就是ISO8859_1，包括操作系统Linux和数据库MySQL等。这样，如果指定Jive统一编码为ISO8859_1，那么就有下面3个环节必须把握：

　　开发和编译代码时指定字符集为ISO8859_1。

　　运行操作系统的默认编码必须是ISO8859_1，如Linux。

　　在JSP头部声明：<%@ page contentType="text/html;charset=ISO8859_1" %>。

　　（2）如果统一指定为GBK中文字符集，上述3个环节同样需要做到，不同的是只能运行在默认编码为GBK的操作系统，如中文Windows。

　　统一编码为ISO8859_1和GBK虽然带来编制代码的方便，但是各自只能在相应的操作系统上运行。但是也破坏了Java跨平台运行的优越性，只在一定范围内行得通。例如，为了使得GBK编码在linux上运行，设置Linux编码为GBK。

　　那么有没有一种除了应用系统以外不需要进行任何附加设置的中文编码根本解决方案呢？

　　将Java/J2EE系统的统一编码定义为UTF-8。UTF-8编码是一种兼容所有语言的编码方式，惟一比较麻烦的就是要找到应用系统的所有出入口，然后使用UTF-8去“结扎”它。

　　一个J2EE应用系统需要做下列几步工作：

开发和编译代码时指定字符集为UTF-8。JBuilder和Eclipse都可以在项目属性中设置。
使用过滤器，如果所有请求都经过一个Servlet控制分配器，那么使用Servlet的filter执行语句，将所有来自浏览器的请求（request）转换为UTF-8，因为浏览器发过来的请求包根据浏览器所在的操作系统编码，可能是各种形式编码。关键一句：
request.setCharacterEncoding("UTF-8")。
网上有此filter的源码，Jdon框架源码中com.jdon.util.SetCharacterEncodingFilter
需要配置web.xml 激活该Filter。
在JSP头部声明：<%@ page contentType="text/html;charset= UTF-8" %>。
在Jsp的html代码中，声明UTF-8:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
设定数据库连接方式是UTF-8。例如连接MYSQL时配置URL如下：
jdbc:mysql://localhost:3306/test?useUnicode=true&amp;characterEncoding=UTF-8
一般数据库都可以通过管理设置设定UTF-8
其他和外界交互时能够设定编码时就设定UTF-8，例如读取文件，操作XML等。
　　　　 笔者以前在Jsp/Servlet时就采取这个原则，后来使用Struts、Tapestry、EJB、Hibernate、Jdon等框架时，从未被乱码困扰过，可以说适合各种架构。希望本方案供更多初学者分享，减少Java/J2EE的第一个拦路虎，也避免因为采取一些临时解决方案，导致中文问题一直出现在新的技术架构中。
　　相关J2EE中文问题解决的源码系统可参考：按这里

　　欢迎进入讨论 也欢迎提出例外案例