linux java修改defaultcharset,-Dfile.encoding与Charset.defaultCharset
Charset.defaultcharset(),指的是jvm操作输入流、输出流时，所使用的编码。jvm一旦启动就不能修改jvm默认字符集。可以通过设置-Dfile.encoding=UTF-8，来初始化jvm的字符集
file.encoding，是比较旧的参数，好像是JDK版本最初的版本有，这个参数可以设置Charset.defaultcharset()。
file.encoding可以通过System.setProperty("file.encoding","GBK")修改,但是仅仅是修改了file.encoding这个属性值，并不会影响，Charset.defaultcharset，因为Charset.defaultcharset()启动jvm时就初始化了
我的理解：
1、class文件编码方式：都说class文件是unicode编码，但到底是UTF-8还是UTF-16都说不清。
2、jvm编码：jvm编码都是Unicode(utf-16)编码
3、string编码：在jvm内存中始终是unicode(utf-16)编码。
Charset.defaultcharset影响默认字节流、字符流的编码、解码方式，比如
file.encoding=utf-8，影响了Charset.defaultcharset()，从而
“中”.getBytes() 3个字节
file.encoding=GBK，影响了Charset.defaultcharset()，从而
“中”.getBytes() 2个字节
file.encoding=utf-16，影响了Charset.defaultcharset()，从而
“中”.getBytes() 4个字节
java文件---java complier---class文件---jvm---操作系统---界面
java文件：任何文件都有一个编码，同样java文件也有个编码方式
java complier: javac -encoding UTF-8 xx.java，可以指定编码方式编译java文件，如果不指定，java编译器会读取file.encoding来默认对待java原文件，而file.encoding默认是依赖操作系统的默认编码的
class文件：传说是unicode 编码，也就是utf-16编码
jvm：jvm编码都是Unicode(utf-16)编码
界面乱码：可能的原因。界面是GBk，而输出的流是utf-8，如果界面没有自动转换就会出现乱码
windows控制台(cmd)乱码问题：
windows操作系统的控制台有的时候输出汉语会是乱码，这是因为windows控制输出编码是GBK，java程序的-Dfile.encoding=utf8 定义输出的流是utf-8编码的，windows控制台不会自动转换，所以就会出现乱码，如果将-Dfile.encoding=GBK就不会乱码了。
经过我实际测试charset.defaultcharset受java源文件或者说，受执行java命令的客户端影响
1、eclipse中，分别写了两个类，方法是一样的，一个是utf-8编码，一个是utf-16编码，utf-8编译后输出utf-8，utf-16编译后，utf-16输出utf-16
2、客户端(windows命令行，默认就是gbk代码页)中，不指定file.encoding，这俩文件都输出gbk
经过上述两个测试，觉得，charset受客户端环境影响
class文件---->界面这一部是否出现乱码
1、客户端会自动转码，那就简单了只要客户端能自动识别输入流的编码，然后转换成字符肯定是不会乱码的。这么说也不严谨，还要看客户端有没有这个字符集。比如utf-8---->gbk，如果客户端自动转码并且有字符集，那么肯定不会乱码
2、客户端不会自动转码，那输入流就必须是客户端的编码，不然，肯定会出乱码
还余下的问题：class文件是什么编码，需要读取javac的源码看看生成的class文件到底是使用的什么编码？
最终结论：
开发中，将jvm设置-Dfile.encoding=UTF8
eclipse下，window--->preferences---->installed jres---->edit--->-Dfile.encoding=UTF8
Tomcat单独启动，windows系统下，修改catalina.bat，设置 set JAVA_OPTS=-Dfile.encoding=UTF8
linux系统下,设置JAVA_OPTS=-Dfile.encoding=UTF8
这样设置，jvm读取文件(属性文件、xml文件、输入流、输出流)都会以utf8的方式操作