本篇JAVA程序实例将会大家讲解Java编程这一知识点，看完这篇文章会让你对Java编程的知识点有更加清晰的理解和运用。

调整Java资源

调整Java虚拟机（JVM）可以提高性能减少内存消耗。

本页面的主题：

关于垃圾收集

选择一个Java垃圾收集器

将G1设置为Java垃圾收集器

确定堆大小

Cassandra如何使用内存 - 请先阅读以便更好地理解本主题中的设置和建议。

调整其他Cassandra服务的JVM参数

其他JMX选项

关于垃圾收集

垃圾收集是Java从内存中删除不再需要的数据的过程。为了获得最佳性能，选择正确的垃圾收集器和堆大小设置非常重要。

你一定要最小化的一种情况是垃圾收集暂停，也称为“停止世界”事件。当内存区域已满并且JVM需要腾出空间继续时，会发生暂停。在暂停期间，所有操作都暂停。由于暂停会影响网络，因此节点可能会显示为集群中的其他节点。另外，任何Select和Insert语句都会等待，这会增加读取和写入延迟。应该避免任何一秒以上的停顿，或者一秒钟内多次暂停，这会增加大部分的秒数。问题的根本原因是存储在内存中的数据的速度超过了数据可以被删除的速度。有关特定的症状和原因，请参阅垃圾回收暂停。

选择一个Java垃圾收集器

对于Cassandra 3.0及更高版本，使用Concurrent-Mark-Sweep（CMS）或G1垃圾收集器取决于以下因素：

1.建议在以下情况下使用G1：

堆大小从14 GB到64 GB。

G1对于较大的堆执行效果要好于CMS，因为它首先扫描包含大多数垃圾对象的堆的区域，并在堆栈中进行压缩，而CMS在执行垃圾回收时会停止应用程序。

工作负载是可变的，也就是说，集群一直在执行不同的进程。

为了将来考虑，CMS将在Java 9中被弃用。

G1更容易配置。

G1是自我调节。

2.在以下情况下推荐使用CMS：

您有时间和专业知识来手动调整和测试垃圾回收。

请注意，为堆分配更多的内存可能会导致性能下降，因为垃圾收集工具增加了堆内存中Cassandra元数据的数量。

堆大小不超过14 GB。

工作负载是固定的，也就是说，集群始终执行相同的过程。

环境需要尽可能低的延迟。由于分析，G1会导致一些延迟。

注：有关配置CMS的帮助，请联系DataStax服务团队。

将G1设置为Java垃圾收集器

打开jvm.options。

注释掉该-Xmn800M行。

注释掉### CMS Settings部分中的所有行。

取消注释部分中的相关G1设置### G1 Settings ：

?

 ## Use the Hotspot garbage-first collector.

-XX:+UseG1GC

## Have the JVM do less remembered set work during STW, instead

## preferring concurrent GC. Reduces p99.9 latency.

#-XX:G1RSetUpdatingPauseTimePercent=5

注意：使用G1时，只需要设置MAX_HEAP_SIZE。

确定堆大小

您可能会试图设置Java堆来占用计算机的大部分RAM。但是，这会干扰操作系统页面缓存的操作。操作系统为经常访问的数据维护OS页面缓存，并将这些数据保存在内存中。正确地调整OS页面缓存通常会比增加Cassandra行缓存带来更好的性能。

Cassandra根据以下公式自动计算最大堆大小（MAX_HEAP_SIZE）：

?

1 max(min(1/2 ram, 1024MB), min(1/4 ram, 8GB)

对于生产用途，您可能希望使用以下准则调整环境的堆大小：

堆大小通常在系统内存的?和?之间。

不要把所有的内存堆放在堆上，因为它也用于离堆缓存和文件系统缓存。

调整GC时始终启用GC记录。

逐渐调整设置并测试每个增量更改。

启用GC的并行处理，特别是在使用DSE搜索时。

Cassandra的GCInspector类记录有关任何垃圾收集的时间超过200毫秒的信息。垃圾收集频繁发生并需要一定的时间（秒）才能完成，这表明JVM上的垃圾收集压力过大。除了调整垃圾收集选项之外，其他的补救措施还包括添加节点以及降低缓存大小。

对于使用G1的节点，Cassandra社区建议尽可能大的MAX_HEAP_SIZE，最大为64 GB。

注意： 有关更多调整技巧，请参阅Secret HotSpot选项，以改善大堆中的GC暂停。

MAX_HEAP_SIZE

建议的最大堆大小取决于使用哪个GC：

硬件设置 推荐MAX_HEAP_SIZE

旧计算机 通常8 GB

适用于新型计算机（8+核心）的CMS，最高可达256 GB RAM 没有更多的14 GB

G1用于更新的计算机（8+核心），最高可达256 GB RAM 14 GB到64 GB

为您的环境确定最佳堆大小的最简单方法是：

将jvm.options文件中的最大堆大小设置为单个节点上的高任意值。例如，使用G1时：

?

-Xms48G

-Xmx48G

将min（-Xms）和max（-Xmx）堆大小设置为相同的值，以避免在调整大小期间停止GC世界的暂停，并在启动时锁定内存中的堆，以防止其中的任何内容被换出。

启用GC日志记录。

检查日志以查看该节点使用的堆，并使用该值设置群集中的堆大小：

注意：此方法会降低测试节点的性能，但通常不会显着降低群集性能。

HEAP_NEWSIZE

对于CMS，您可能还需要调整HEAP_NEWSIZE。此设置确定分配给newer objects或young generation的堆内存量。Cassandra计算此属性的默认值（以MB为单位）：

内核数的100倍

?MAX_HEAP_SIZE

作为一个起点，将HEAP_NEWSIZE设置为每个物理CPU核心100 MB。例如，对于一个现代的8核心+机器：

?

-Xmn800M

较大的HEAP_NEWSIZE会导致更长的GC暂停时间。对于较小的HEAP_NEWSIZE，GC暂停较短，但通常较expensive。

Cassandra如何使用内存

Cassandra在JVM堆中执行以下主要操作：

为了执行读取，Cassandra在堆内存中维护以下组件：

Bloom filters（布隆过滤器）

Partition summary（分区摘要）

Partition key cache（分区键缓存）

Compression offsets（压缩偏移）

SSTable index summary（SSTable索引摘要）

Cassandra收集副本read或anti-entropy repair，并比较堆内存中的副本。

写入Cassandra的数据首先存储在堆内存的memtables中。Memtables被刷新到磁盘上的SSTables。

注意：这些元数据驻留在内存中，并且与总数据成正比。一些组件与总内存大小成比例的增长。

为了提高性能，Cassandra也使用堆外存储器，如下所示：

页面缓存。当读取磁盘上的文件时，Cassandra使用额外的内存作为页面缓存。

布隆过滤器和压缩偏移映射位于堆外。

Cassandra可以将缓存的rows存储在Java堆外的本机内存中。这减少了JVM堆的需求，这有助于将堆大小保持在JVM垃圾回收性能的最佳位置。

调整其他Cassandra服务的JVM参数

Solr：一些Solr用户报告说，增加堆栈大小可以提高Tomcat的性能。

要增加堆栈大小，请取消注释并修改cassandra-env.sh文件中的默认设置 。

另外，减少memtable空间为Solr缓存腾出空间可以提高性能。通过更改cassandra.yaml文件中的memtable_heap_space_in_mb和memtable_offheap_space_in_mb属性来 修改memtable空间。

?

 # Per-thread stack size.

JVM_OPTS="$JVM_OPTS -Xss256k"

MapReduce：由于MapReduce在JVM之外运行，对JVM的更改不会直接影响Analytics / Hadoop操作。

其他JMX选项

Cassandra通过Java Management Extensions（JMX）公开统计和管理操作。JConsole和nodetool是符合JMX的管理工具。

通过在cassandra-env.sh中编辑这些属性来配置Cassandra进行JMX管理 。

com.sun.management.jmxremote.port：设置Cassandra从JMX连接侦听的端口。

com.sun.management.jmxremote.ssl：为JMX启用或禁用SSL。

com.sun.management.jmxremote.authenticate：启用或禁用JMX的远程认证。

-Djava.rmi.server.hostname：设置JMX应该用来连接的接口主机名或IP。如果连接有问题，请取消注释并设置。

注意：默认情况下，您可以使用端口7199上的JMX与Cassandra进行交互，而无需进行身份验证。

以上，关于Java的全部内容讲解完毕啦，欢迎大家继续关注!更多关于Java的干货请关注职坐标Java频道!