(quote)some problems in java development java开发的常见问题（转载）

问题一：做数据库缓存时遇到的问题。HashMap在并发遍历时会报ConcurrentModificationException，即使使用Collections.synchronizedList把Map包起来还是会报这个异常，这个问题很简单，解决办法也简单。第一种解决办法是不要用Map的iterator来遍历，而是用Set（Map.keySet方法）的toArray方法来遍历，这种办法虽然会损耗一定的性能和内存，但比在方法前加synchronized好得多；第二种解决办法用jdk5.0以后的ConcurrentHashMap来实现。【修正：经过测试和验证，第一种方法不行，也就是并发操作MAP而且要求遍历的时候只能用ConcruuentHashMap，在此要感谢写ConcurrentHashMap的专家们。】

问题二：jfreecharts在Linux上不能显示中文，这个问题没有费多长时间就解决了，上网一搜就搞定，解决方法如下： 到网上下载一个linux下的ttf字体，本例用的是zysong.ttf 1.确认%JavaHome%/jre/lib/fonts目录下存在zysong.ttf 2.在%JavaHome%/jre/lib/fonts目录下执行"ttmkfdir -o fonts.dir"命令,重新生成fonts.dir文件 3.确认/usr/share/fonts/zh_CN/TrueType目录存在,如果不存在则mkdir创建 4.确认/usr/share/fonts/zh_CN/TrueType目录下存在zysong.ttf 5.在%JavaHome%/jre/lib目录下,执行 cp fontconfig.RedHat.3.properties.src fontconfig.properties 6.重起resin，OK。
问题三：linux下的too many open files错误，这个问题比较严重，AS4默认打开文件数是1024，如果超过这个数，resin就自动down掉了，非常恶心。解决办法如下： echo 65536 > /proc/sys/fs/file-max 编辑/etc/sysctl.conf 文件，编辑行 fs.file-max = 65536 编辑文件/etc/security/limits.conf，增加行 * - nofile 65536 用ulimit -a 查看，如果看到行open files (-n) 65536就说明对了

问题四：内存泄露，表现出来的特征是CPU占到99.9%，内存由10%左右经过几个小时后慢慢涨到50%，最后死掉。做java的人知道，这个问题非常痛苦，而且没有很好的解决办法，因为直接看代码很难看出来。我原来一直以为问题会出现在缓存上，但仔细想想apache的LRUMap不至于产生内存泄露，尤其我设置了LRUMap最大长度只有10000，10000个内存对象能有多大，后来发现是SmartUpload的问题，改成apache的FileUpload子项目就可以了。另外，我在设置jvm参数时增加了-Xmx2048m -Xms2048m -Xmn768m -Xss512k -XX:+UseParallelGC -XX:ParallelGCThreads=4 -XX:+UseParallelOldGC -XX:+UseAdaptiveSizePolicy这些参数，可以回收年老区的内存，现在比较稳定，一般内存占到27%左右就不会再涨了，可能这些参数还不是最优的，有待探索。另外查找内存泄露的软件JProbe我也玩了玩，的确看出其他代码没有明显内存泄露。【修正：上面的参数配置狗P用都没有，内存总是一直在涨。我还尝试了用其他不同方法去回收内存，结果都不太好使，直接用jvm默认的回收方式是最好的，也就是只配置两个参数-Xmx768M -Xms768M效果最好，这样java才真的可以一次性回收几百兆的内存。】

题九：hiberate配置文件的问题，配置不好的话总是会报NESTED Exception，或者多用户并发的时候报错。我想一般人都遇到过了，增加一个c3p0的配置段，尤其注意max_statements设置稍微大一点，原来我设置为100的时候10个用户同时创建记录就会出错。 org.hibernate.connection.C3P0ConnectionProvider 200 20 3600 1000 300 5 false