IBM的OpenJ9

Posted 2021-03-06 smileblogs

安华金和攻防实验室2018年提交给IBM的OpenJ9漏洞于近日完成修复,IBM推出补丁。由于这个漏洞(CVE-2018-12547)影响IBM产品多达400+、攻击复杂度低、危害大,CVE漏洞危害评分高达9.8。安华金和特此向广大用户告警,提醒OpenJ9用户及时下载IBM官网最新公布的补丁。

OpenJ9是IBM自1997年以来一直主推的高性能JVM产品,是IBM Java产品中的核心组件。几乎所有IBM成熟产品都依赖于OpenJ9,仅IBM自主产品就有419个产品受到此漏洞影响具体列表请见下面的链接。不仅IBM全线产品依赖OpenJ9,由于2017年OpenJ9开源,无数追求性能的第三方流行软件也都使用了OpenJ9。我们有理由相信该高危漏洞影响的主流产品不下千款。IBM特此对于安华金和在安全研究方面所做出的努力和贡献进行了特别的感谢。

 

http://science.china.com.cn/2019-07/03/content_40807930.htm

java -server -Xmx最大内存M -Xms最小内存M -Xss512K -Xaggressive -Xalwaysclassgc [-XcompilationThreads4] -Xconmeter:dynamic [-Xgcpolicy:metronome] -Xshareclasses [-Xtune:virtualized] -jar 服务端核心.jar

 

参数解释

-server
服务器运行模式，为持久运行优化

-Xms
初始堆大小，一般是物理内存的1/64(<1GB)，和-Xmx一样大可以节省一点CPU资源

-Xmx
最大堆大小，一般是物理内存的1/4(<1GB)，不过MC服务端对于内存的要求挺高的，能用上的都用上吧

-Xss
每个线程的堆栈大小，OpenJ9默认是1024KB，不过另一位服主的帖指出，对于MC，512KB足够了

-Xaggressive
更激进的性能优化，OpenJ9的文档指出它会在未来版本作为默认选项

-Xalwaysclassgc
始终在全局垃圾回收期间执行动态类卸载检查，减少内存占用

-XcompilationThreads4
指定JIT编译器使用的编译线程数，最高只能设到4，如果服务器物理核心不足4个，设置成物理核心的一半

-Xconmeter:dynamic
动态检测大对象区或小对象区域的使用情况

-Xgcpolicy:metronome
启用metronome垃圾收集器，可以让垃圾收集时的瞬卡更短暂。仅支持AIX(没人用这个开MC服吧)和Linux，Windows就不要加了。

-Xshareclasses
OpenJ9的高速类共享功能，减少内存占用与启动时间，适合多个JVM运行相似代码的环境，或定期重启JVM的环境，对于群组服非常有用。

-Xtune:virtualized
假如你的服务器运行在虚拟化环境中(例如阿里云、腾讯云等等)，使用这一选项可以在空闲时减少OpenJ9 VM CPU消耗，有可能会略微提升性能与减少内存占用，不过代价是吞吐量的少量损失。实体机环境不要加! 
注意事项

1.此优化仅适用于OpenJ9
2.优化效果因环境差异可能会不同