表结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

CREATE TABLE `scheduler_task_tracker` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `task_id` int(11) DEFAULT NULL,
  `task_start_time` datetime DEFAULT NULL,
  `task_status` int(11) DEFAULT NULL,
  `task_end_time` datetime DEFAULT NULL,
  `scheduler_node` varchar(255) DEFAULT NULL,
  `client_node` varchar(255) DEFAULT NULL,
  `is_execute_notify` int(11) DEFAULT NULL,
  `partition_code` varchar(255) DEFAULT NULL,
  `is_del` smallint(6) DEFAULT NULL,
  `task_name` varchar(500) DEFAULT NULL,
  `user_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `task_start_time_ind` (`task_start_time`),
  KEY `task_end_time_ind` (`task_end_time`),
  KEY `task_name_ind` (`task_name`(255)) USING BTREE,
  KEY `task_id_partition_code_ind` (`task_id`,`partition_code`)
) ENGINE=InnoDB AUTO_INCREMENT=21614019 DEFAULT CHARSET=utf8

索引信息

task_start_time的Cardinality： 3453770
task_end_time的Cardinality： 6907541

查询SQL

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

explain 
SELECT
			id AS taskTrackerID,
			task_id AS taskInstanceId,
			task_start_time AS taskStartTime,
			is_debug AS isDebug,
			task_status AS taskStatus,
			task_progress AS taskProgress,
			task_end_time AS taskEndTime,
			scheduler_node AS schedulerNode,
			is_del AS isDel,
			client_node AS clientNode,
			user_id AS userId,
			partition_code AS partitionCode,
			task_name AS taskName
		FROM
			scheduler_task_tracker
		WHERE
	task_status = 6
    and task_name LIKE '%rpt_c2c_sell_vr_report_di%' 
    and task_start_time >='2020-03-01 00:00:00' 
    and task_end_time<='2020-03-02 23:59:59' 
    ORDER BY  task_start_time asc 
    limit 0, 10

1. 查询按照 task_start_time 排序，走索引’task_start_time_ind’ 扫描：78462行，较快
   

2. 查询按照 task_end_time 排序，走索引’task_end_time_ind’ 扫描：3454055行 ，比较慢
   

分析如下：

• task_name 有索引但用了 like 不走这个索引
• 因为有了排序 1，2 查询都按照排序字段上的索引来查询
• task_end_time基数太大所以扫描的行数多，查询慢

怎么使得第二个查询变快呢？

• 可以建立task_start_time和task_end_time的联合查询

mysql主要根据优化器来判断使用那个索引还是使用全表扫描

• 优化器优化判断的指标
  需要扫描的行数，是否使用临时表，是否排序等因素来计数查询的成本
• 扫描行数判断
  那么优化器是怎么获取扫描的总行数的，其实就和抽样检查类似，因为索引是有序的，就可以使用采样统计这种算法算出大概的扫描行数，可以通过show index查看索引的Cardinality预估值。

表结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

CREATE TABLE `scheduler_task_tracker` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `task_id` int(11) DEFAULT NULL,
  `task_start_time` datetime DEFAULT NULL,
  `task_status` int(11) DEFAULT NULL,
  `task_end_time` datetime DEFAULT NULL,
  `scheduler_node` varchar(255) DEFAULT NULL,
  `client_node` varchar(255) DEFAULT NULL,
  `is_execute_notify` int(11) DEFAULT NULL,
  `partition_code` varchar(255) DEFAULT NULL,
  `is_del` smallint(6) DEFAULT NULL,
  `task_name` varchar(500) DEFAULT NULL,
  `user_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `task_start_time_ind` (`task_start_time`),
  KEY `task_end_time_ind` (`task_end_time`),
  KEY `task_name_ind` (`task_name`(255)) USING BTREE,
  KEY `task_id_partition_code_ind` (`task_id`,`partition_code`)
) ENGINE=InnoDB AUTO_INCREMENT=21614019 DEFAULT CHARSET=utf8

索引信息

task_start_time的Cardinality： 3453770
task_end_time的Cardinality： 6907541

查询SQL

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

explain 
SELECT
			id AS taskTrackerID,
			task_id AS taskInstanceId,
			task_start_time AS taskStartTime,
			is_debug AS isDebug,
			task_status AS taskStatus,
			task_progress AS taskProgress,
			task_end_time AS taskEndTime,
			scheduler_node AS schedulerNode,
			is_del AS isDel,
			client_node AS clientNode,
			user_id AS userId,
			partition_code AS partitionCode,
			task_name AS taskName
		FROM
			scheduler_task_tracker
		WHERE
	task_status = 6
    and task_name LIKE '%rpt_c2c_sell_vr_report_di%' 
    and task_start_time >='2020-03-01 00:00:00' 
    and task_end_time<='2020-03-02 23:59:59' 
    ORDER BY  task_start_time asc 
    limit 0, 10

1. 查询按照 task_start_time 排序，走索引’task_start_time_ind’ 扫描：78462行，较快
   

2. 查询按照 task_end_time 排序，走索引’task_end_time_ind’ 扫描：3454055行 ，比较慢
   

分析如下：

• task_name 有索引但用了 like 不走这个索引
• 因为有了排序 1，2 查询都按照排序字段上的索引来查询
• task_end_time基数太大所以扫描的行数多，查询慢

怎么使得第二个查询变快呢？

• 可以建立task_start_time和task_end_time的联合查询

mysql主要根据优化器来判断使用那个索引还是使用全表扫描

• 优化器优化判断的指标
  需要扫描的行数，是否使用临时表，是否排序等因素来计数查询的成本
• 扫描行数判断
  那么优化器是怎么获取扫描的总行数的，其实就和抽样检查类似，因为索引是有序的，就可以使用采样统计这种算法算出大概的扫描行数，可以通过show index查看索引的Cardinality预估值。

最近几周专门研究了一下事务相关的一些理论和原理，把我之前那些模棱两可的东西总算搞明白了些，那么接下来我将写一系列的文章把整个知识体系都梳理一遍。一来是把这些知识都记录下来，方便以后查看，二来是把这些分享给对这些知识还不太清楚的同学。
我大概分以下几个主题来介绍：

• 从0到1学事务-事务理论介绍
• 从0到1学事务-mysql中事务的实现
• 从0到1学事务-在spring中使用事务
• 从0到1学事务-分布式事务介绍
• 从0到1学事务-分布式事务之XA
• 从0到1学事务-分布式事务之BASE
• 从0到1学事务-分布式事务之seata

由于本人水平有限，对其中理解不到位的欢迎各位同学指正，共同进步！

知乎上有人提问：fastjson这么快，为啥老外还是热衷 jackson? 下面是甘明的回答，从各个方面分析了这个问题：
哈哈哈，我来回答这个问题！
因为我实在是对这两个库太熟悉了。

在云HBase值班的时候，经常会遇见有用户咨询诸如“HBase是否支持连接池？”这样的问题，也有用户因为应用中创建的Connection对象过多，触发了zookeeper的连接数限制，导致客户端连不上的。究其原因，都是因为对HBase客户端的原理不了解造成的。本文简单介绍HBase客户端的Connection对象与socket连接的关系，并给出Connection的正确用法。

HBase是BigTable的开源实现，事务模型也与BigTable一脉相承 – 仅支持行级别的事务。虽然Jeff Dean大神在接受采访时公开承认目前在技术领域最后悔的事情就是没有在BigTable中加入跨行事务模型，以至于之后很多团队都在BigTable之上重复造各种各样的分布式事务轮子。这点笔者是认同的，现在确实有很多团队在HBase之上造了很多轮子（Tephra | Trafodian | Omid），试想如果这个工作做在了BigTable里面，这些团队的人是不是可以做更多其他有意义的事情了~ 所幸的是之后Google又发布了一篇介绍分布式事务模型的的paper – Percolator，现在很多团队都参考该论文实现分布式事务，包括TiDB、Omid等，也算是一种弥补吧。
虽说HBase目前只支持行级事务，但行级事务也是事务！麻雀虽小，肝脏具全。这篇文章一起看看HBase行级事务所满足的ACID特性。下文中隔离性部分基本翻译文章《Apache HBase Internals: Locking and Multiversion Concurrency Control》，大家可以阅读原文。

在hbase0.98之前hbase元数据表有两个：ROOT表与meta表。在hbase0.98之后，hbase就废弃了ROOT表，仅保留meta并且该表不允许split,所以只有一个Region。

meta表位置

meta表保存了集群中所有region的位置信息，当我们通过客户端put,get,delete等操作数据的时候，首先会去这个表里查找该数据所在的regionserver位置。
但是 meta表也是一个hbase表，那怎么找个表的regionserver呢？答案时：通过zookeeper。
hbsse把meta表的region信息保存到了zookeeper里，对应路径为：/hbase/meta-region-server

meta表结构信息

rowkey为：**表名,该region的startKey,创建时间.hash值**。
其中：hash值为：MD5Hash.getMD5AsHex(byte(表名,该region的startKey,创建时间))
如果当前region为table的第一个region时，region startKey=null

meta表只有一个列簇info，并且包含四列：

1. regioninfo ：当前region的startKey与endKey，name，encode等消息
2. seqnumDuringOpen：
3. server：region所在服务器及端口
4. serverstartcode：服务开始的时候的timestamp

背景

最近我开发了一个基于springboot的服务,服务从网络接收请求，再把请求任务放入队列里交给线程池取异步消费请求任务。
后来发现这个服务有个bug修复后需要重新发布到线上，这时需要停止服务更新jar包，那么我们怎么样停止服务才能保证任务队列里的请求都处理完成了呢？不然有可能会丢掉一些请求。这在高并发流量的服务很常见。

停止进程

linux中停止进程的方式主要使用kill命令，该命令后面可以接信号量参数，这个信号量会传递给相应进程并根据信号执行相应的处理

1

kill [-s 信号声明 | -n 信号编号 | -信号声明] 进程号 

常用的停止进程的信号有两种：

Java服务停止方式

我们知道使用kill -15 可以向进程发送一个通知告知现在要关闭服务，请做好善后工作。那么Java中怎么响应这个通知呢？
Java提供了shutdown hook的勾子机制，通过调用

1

Runtime.getRuntime().addShutdownHook(Thread hook);

可以向jvm注册一个线程，当执行kill -15的时候jvm会调用这个线程并等待这个线程执行完毕，最后退出jvm。

springboot优雅停止方式

springboot应用本质上是一个Java应用，所以停止原理就如上面所述。
但是实际上springboot服务可能很复杂，依赖的资源比较多。怎么保证按照指定的顺序关闭资源呢？
举例如下：
我们 springboot 依赖的redis ,并且里面有个ScheduledExecutorService 线程池 定时从队列里面读取任务执行，任务里面使用了RedisTemplate操作redis。
我注册了 shutdownHook 来关闭线程池，如下

1
2
3
4

HookUtils.addShutdownHook(() -> {
     log.info("ScheduledExecutorService Name[{}] shutdown",poolName);
     gracefulShutdown(scheduledExecutorService,0);
   });

但是，当我执行kill -15 关闭进程的时候，却在控制台发现了如下异常

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

2020-02-14 18:12:47.666 [Thread-7] INFO  com.xxx.xxx.xxx.executor.master.component.task.TaskProgressManager - ScheduledExecutorService Name[xxx] shutdown finished
2020-02-14 18:12:47.671 [Thread-7] INFO  org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor - Shutting down ExecutorService 'applicationTaskExecutor'
2020-02-14 18:12:47.680 [xxx] WARN  com.xxx.xxx.xxx.executor.master.component.mq.RedisMessageHandler - Read error from redis command queue
org.springframework.data.redis.RedisSystemException: Redis exception; nested exception is io.lettuce.core.RedisException: io.lettuce.core.RedisException: Connection closed
	at org.springframework.data.redis.connection.lettuce.LettuceExceptionConverter.convert(LettuceExceptionConverter.java:74) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]
	at org.springframework.data.redis.connection.lettuce.LettuceExceptionConverter.convert(LettuceExceptionConverter.java:41) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]
	at org.springframework.data.redis.PassThroughExceptionTranslationStrategy.translate(PassThroughExceptionTranslationStrategy.java:44) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]
	at org.springframework.data.redis.FallbackExceptionTranslationStrategy.translate(FallbackExceptionTranslationStrategy.java:42) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]
	at org.springframework.data.redis.connection.lettuce.LettuceConnection.convertLettuceAccessException(LettuceConnection.java:268) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]
	at org.springframework.data.redis.connection.lettuce.LettuceListCommands.convertLettuceAccessException(LettuceListCommands.java:490) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]
	at org.springframework.data.redis.connection.lettuce.LettuceListCommands.bRPop(LettuceListCommands.java:409) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]
	at org.springframework.data.redis.connection.lettuce.LettuceClusterListCommands.bRPop(LettuceClusterListCommands.java:82) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]
	at org.springframework.data.redis.connection.DefaultedRedisConnection.bRPop(DefaultedRedisConnection.java:535) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]
	at org.springframework.data.redis.core.DefaultListOperations$5.inRedis(DefaultListOperations.java:215) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]
	at org.springframework.data.redis.core.AbstractOperations$ValueDeserializingRedisCallback.doInRedis(AbstractOperations.java:59) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]
	at org.springframework.data.redis.core.RedisTemplate.execute(RedisTemplate.java:224) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]
	at org.springframework.data.redis.core.RedisTemplate.execute(RedisTemplate.java:184) ~[spring-data-redis-2.1.5.RELEASE.jar:2.1.5.RELEASE]

这个是在执行线程池里的任务时发行redis连接已经关闭了抛出的异常。
所以这里需要先把线程池里的任务执行完毕在关闭redis连接，那么我们怎么控制这个顺序呢？
执行kill -15的时候，spring会执行一个shutdown hook 这个hook里会执行关闭动作。这个hook 在 AbstractApplicationContext 里注册

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@Override
	public void registerShutdownHook() {
		if (this.shutdownHook == null) {
			// No shutdown hook registered yet.
			this.shutdownHook = new Thread() {
				@Override
				public void run() {
					synchronized (startupShutdownMonitor) {
						doClose();
					}
				}
			};
			Runtime.getRuntime().addShutdownHook(this.shutdownHook);
		}
	}

最终调用在 doClose 方法里

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

/**
	 * Actually performs context closing: publishes a ContextClosedEvent and
	 * destroys the singletons in the bean factory of this application context.
	 * <p>Called by both {@code close()} and a JVM shutdown hook, if any.
	 * @see org.springframework.context.event.ContextClosedEvent
	 * @see #destroyBeans()
	 * @see #close()
	 * @see #registerShutdownHook()
	 */
	protected void doClose() {
		// Check whether an actual close attempt is necessary...
		if (this.active.get() && this.closed.compareAndSet(false, true)) {
			if (logger.isDebugEnabled()) {
				logger.debug("Closing " + this);
			}

			LiveBeansView.unregisterApplicationContext(this);

			try {
				// Publish shutdown event.
				publishEvent(new ContextClosedEvent(this));
			}
			catch (Throwable ex) {
				logger.warn("Exception thrown from ApplicationListener handling ContextClosedEvent", ex);
			}

			// Stop all Lifecycle beans, to avoid delays during individual destruction.
			if (this.lifecycleProcessor != null) {
				try {
					this.lifecycleProcessor.onClose();
				}
				catch (Throwable ex) {
					logger.warn("Exception thrown from LifecycleProcessor on context close", ex);
				}
			}

			// Destroy all cached singletons in the context's BeanFactory.
			destroyBeans();

			// Close the state of this context itself.
			closeBeanFactory();

			// Let subclasses do some final clean-up if they wish...
			onClose();

			// Reset local application listeners to pre-refresh state.
			if (this.earlyApplicationListeners != null) {
				this.applicationListeners.clear();
				this.applicationListeners.addAll(this.earlyApplicationListeners);
			}

			// Switch to inactive.
			this.active.set(false);
		}
	}

doClose 会执行

1. 发布cotext close event 事件通知
2. Stop all Lifecycle beans
3. 销毁所有的单例bean(会调用bean的destory方法)
4. 关闭beanFactory

我们知道向jvm注册的多个hook，但多个hook是并行执行的并没有先后顺序。所以要保持先后顺序必须要在一个hook里执行关闭和回收资源等操作，这样我们只能在spring hook里做了。
从上面看，redis 关闭资源连接等操作应该是在第三步 销毁bean里面做的，所以我们可以在第1步里监听ContextClosedEvent事件，在事件回调方法里面做，只要实现ApplicationListener 接口即可 如下：

1
2
3
4
5
6
7
8
9

@Override
  public void onApplicationEvent(final ContextClosedEvent event) {
    // when spring closed , publish shutdown event before bean destory
    log.debug("ApplicationContext Close Event");
    //回收资源操作
    componentBootstrap.close();
  }

什么是Spring Boot?

Spring Boot是Spring开源组织下的子项目，是Spring组件一站式解决方案，主要是简化了使用Spring的难度，简省了繁重的配置，提供了各种启动器，开发者能快速上手。

官方网站：http://projects.spring.io/spring-boot/
GitHub源码：https://github.com/spring-projects/spring-boot

Spring Boot的优点

** Features **

• Create stand-alone Spring applications
• Embed Tomcat, Jetty or Undertow directly (no need to deploy WAR files)
• Provide opinionated ‘starter’ POMs to simplify your Maven configuration
• Automatically configure Spring whenever possible
• Provide production-ready features such as metrics, health checks and externalized configuration
• Absolutely no code generation and no requirement for XML configuration

1. 独立运行

Spring Boot而且内嵌了各种servlet容器，Tomcat、Jetty等，现在不再需要打成war包部署到容器中，Spring Boot只要打成一个可执行的jar包就能独立运行，所有的依赖包都在一个jar包内。

2. 简化配置

spring-boot-starter-web启动器自动依赖其他组件，简少了maven的配置。

3. 自动配置

Spring Boot能根据当前类路径下的类、jar包来自动配置bean，如添加一个spring-boot-starter-web启动器就能拥有web的功能，无需其他配置。

4. 无代码生成和XML配置

Spring Boot配置过程中无代码生成，也无需XML配置文件就能完成所有配置工作，这一切都是借助于条件注解完成的，这也是Spring4.x的核心功能之一。

5. 应用监控

Spring Boot提供一系列端点可以监控服务及应用，做健康检测。

Spring Boot的缺点

Spring Boot虽然上手很容易，但如果你不了解其核心技术及流程，所以一旦遇到问题就很棘手，而且现在的解决方案也不是很多，需要一个完善的过程。

前言

大家都知道，jvm在启动的时候，会执行默认的一些参数。一般情况下，这些设置的默认参数应对一些平常的项目也够用了。

但是如果项目特别大了，需要增加一下堆内存的大小、或者是系统老是莫明的挂掉，想查看下gc日志来排查一下错误的原因，都需要咱们手动设置这些参数。

各个参数介绍

1.verbose:gc

表示，启动jvm的时候，输出jvm里面的gc信息。格式如下：

1

[Full GC 178K->99K(1984K)， 0.0253877 secs]

解读 ：Full GC 就表示执行了一次Full GC的操作，178K 和99K 就表示执行GC前内存容量和执行GC后的内存容量。1984K就表示内存总容量。后面那个是执行本次GC所消耗的时间，单位是秒。

2.-XX:+printGC

这个打印的GC信息跟上个一样，就不做介绍了。

3.-XX:+PrintGCDetails

打印GC的详细信息。格式如下：

1
2
3
4
5
6
7
8
9
10
11

–Heap
– def new generation   total 13824K, used 11223K [0x27e80000, 0x28d80000, 0x28d80000)
–  eden space 12288K,  91% used [0x27e80000, 0x28975f20, 0x28a80000)
–  from space 1536K,   0% used [0x28a80000, 0x28a80000, 0x28c00000)
–  to   space 1536K,   0% used [0x28c00000, 0x28c00000, 0x28d80000)
– tenured generation   total 5120K, used 0K [0x28d80000, 0x29280000, 0x34680000)
–   the space 5120K,   0% used [0x28d80000, 0x28d80000, 0x28d80200, 0x29280000)
– compacting perm gen  total 12288K, used 142K [0x34680000, 0x35280000, 0x38680000)
–   the space 12288K,   1% used [0x34680000, 0x346a3a90, 0x346a3c00, 0x35280000)
–    ro space 10240K,  44% used [0x38680000, 0x38af73f0, 0x38af7400, 0x39080000)
–    rw space 12288K,  52% used [0x39080000, 0x396cdd28, 0x396cde00, 0x39c80000)

解读：new generation 就是堆内存里面的新生代。total的意思就是一共的，所以后面跟的就是新生代一共的内存大小。used也就是使用了多少内存大小。0x开头的那三个分别代表的是 底边界，当前边界，高边界。也就是新生代这片内存的起始点，当前使用到的地方和最大的内存地点。

eden space 这个通常被翻译成伊甸园区，是在新生代里面的，一些创建的对象都会先被放进这里。后面那个12288K就表示伊甸园区一共的内存大小，91% used，很明显，表示已经使用了百分之多少。后面的那个0x跟上一行的解释一样。

from space 和to space 是幸存者的两个区。也是属于新生代的。他两个区的大小必须是一样的。因为新生代的GC采用的是复制算法，每次只会用到一个幸存区，当一个幸存区满了的时候，把还是活的对象复制到另个幸存区，上个直接清空。这样做就不会产生内存碎片了。

tenured generation 就表示老年代。
compacting perm 表示永久代。由于这两个的格式跟前面我介绍的那个几乎一样，我就不必介绍了。

4.-XX:+PrintGCTimeStamps

打印GC发生的时间戳。格式如下：

1
2

289.556: [GC [PSYoungGen: 314113K->15937K(300928K)] 405513K->107901K(407680K), 0.0178568 secs] [Times: user=0.06 sys=0.00, real=0.01 secs] 
293.271: [GC [PSYoungGen: 300865K->6577K(310720K)] 392829K->108873K(417472K), 0.0176464 secs] [Times: user=0.06 sys=0.00, real=0.01 secs]

解读：289.556表示从jvm启动到发生垃圾回收所经历的的时间。GC表示这是新生代GC（Minor GC）。PSYoungGen表示新生代使用的是多线程垃圾回收器Parallel Scavenge。314113K->15937K(300928K)]这个跟上面那个GC格式一样。

只不过，这个是表示的是新生代，幸存者区。后面那个是整个堆的大小，GC前和GC后的情况。Times这个显而易见，代表GC的所消耗的时间，用户垃圾回收的时间和系统消耗的时间和最终真实的消耗时间。

5.-XX:loggc:log/gc.log

这个就表示，指定输出gc.log的文件位置。（我这里写的log/gc.log就表示在当前log的目录里，把GC日志写到叫gc.log的文件里。）

6.-XX:+PrintHeapAtGC

表示每次GC后，都打印堆的信息。（这个打印的基本格式跟上面第二条的基本类似，我也就不比多说了。）

7.-XX:+TraceClassLoading

监控类的加载。格式如下：

1
2
3
4
5
6
7

•[Loaded java.lang.Object from shared objects file]
•[Loaded java.io.Serializable from shared objects file]
•[Loaded java.lang.Comparable from shared objects file]
•[Loaded java.lang.CharSequence from shared objects file]
•[Loaded java.lang.String from shared objects file]
•[Loaded java.lang.reflect.GenericDeclaration from shared objects file]
•[Loaded java.lang.reflect.Type from shared objects file]

使用这个参数就能很清楚的看到那些类被加载的情况了。

8.-XX:+PrintClassHistogram

跟踪参数。这个按下Ctrl+Break后，就会打印一下信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

num     #instances         #bytes  class name

----------------------------------------------

   1:        890617      470266000  [B

   2:        890643       21375432  java.util.HashMap$Node

   3:        890608       14249728  java.lang.Long

   4:            13        8389712  [Ljava.util.HashMap$Node;

   5:          2062         371680  [C

   6:           463          41904  java.lang.Class

分别显示：序号、实例数量、总大小、类型。
这里面那个类型，B和C的其实就是byte和char类型。

9.-Xmx -Xms

这个就表示设置堆内存的最大值和最小值。这个设置了最大值和最小值后，jvm启动后，并不会直接让堆内存就扩大到指定的最大数值。而是会先开辟指定的最小堆内存，如果经过数次GC后，还不能，满足程序的运行，才会逐渐的扩容堆的大小，但也不是直接扩大到最大内存。

10.-Xmn

设置新生代的内存大小。

11.-XX:NewRatio

新生代和老年代的比例。比如：1：4，就是新生代占五分之一。

12.-XX:SurvivorRatio

设置两个Survivor区和eden区的比例。比如：2：8 ，就是一个Survivor区占十分之一。

13.-XX:+HeapDumpOnOutMemoryError

发生OOM时，导出堆的信息到文件。

14.-XX:+HeapDumpPath

表示，导出堆信息的文件路径。

15.-XX:OnOutOfMemoryError

当系统产生OOM时，执行一个指定的脚本，这个脚本可以是任意功能的。比如生成当前线程的dump文件，或者是发送邮件和重启系统。

16.-XX:PermSize -XX:MaxPermSize

设置永久区的内存大小和最大值。永久区内存用光也会导致OOM的发生。

17.-Xss

设置栈的大小。栈都是每个线程独有一个，所有一般都是几百k的大小。

作者：SimpleSmile
https://www.cnblogs.com/Simple-Object/p/10272326.html