xinzhuxiansheng / blog-notes Goto Github PK

refer to https://blog.csdn.net/weixin_33816300/article/details/91579425

Youtube
refer to https://www.youtube.com/watch?v=BeJu9bMPLGU&t=41s&ab_channel=IntelliJIDEAbyJetBrains

使用#{}参数占位符时，占位符内容会被替换成“？”，然后通过PreparedStatement对象的setXXX()方法为参数占位符设置值；而${}参数占位符内容会被直接替换为参数值。使用#{}参数占位符能够有效避免SQL注入问题，所以我们可以优先考虑使用#{}占位符，当#{}参数占位符无法满足需求时，才考虑使用${}参数占位符

elasticsearch version: 6.3.2 ，索引副本是 1

集群表象： 出现 unsigned 分片

以下是ES进程错误日志

异常栈信息：
[2021-06-16T19:41:46,906][WARN ][o.e.i.c.IndicesClusterStateService] [data-9.159-1] [[flink_job_log_20210616][10]] marking and sending shard fail
ed due to [shard failure, reason [merge failed]]
org.apache.lucene.index.MergePolicy$MergeException: org.apache.lucene.index.CorruptIndexException: docs out of order (52720 <= 52720 ) (resource=
RateLimitedIndexOutput(FSIndexOutput(path="/data1/esdata/nodes/0/indices/8vuyaEy7RqKKX0hveXzR1A/10/index/_1qt_Lucene50_0.doc")))
at org.elasticsearch.index.engine.InternalEngine$EngineMergeScheduler$2.doRun(InternalEngine.java:2113) ~[elasticsearch-6.3.2.jar:6.3.2]
at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:725) ~[elasticsearch
-6.3.2.jar:6.3.2]
at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) ~[elasticsearch-6.3.2.jar:6.3.2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_92]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_92]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_92]
Caused by: org.apache.lucene.index.CorruptIndexException: docs out of order (52720 <= 52720 ) (resource=RateLimitedIndexOutput(FSIndexOutput(path="/data1/esdata/nodes/0/indices/8vuyaEy7RqKKX0hveXzR1A/10/index/_1qt_Lucene50_0.doc")))
at org.apache.lucene.codecs.lucene50.Lucene50PostingsWriter.startDoc(Lucene50PostingsWriter.java:225) ~[lucene-core-7.3.1.jar:7.3.1 ae0705edb59eaa567fe13ed3a222fdadc7153680 - caomanhdat - 2018-05-09 09:27:24]
at org.apache.lucene.codecs.PushPostingsWriterBase.writeTerm(PushPostingsWriterBase.java:141) ~[lucene-core-7.3.1.jar:7.3.1 ae0705edb59eaa567fe13ed3a222fdadc7153680 - caomanhdat - 2018-05-09 09:27:24]
at org.apache.lucene.codecs.blocktree.BlockTreeTermsWriter$TermsWriter.write(BlockTreeTermsWriter.java:864) ~[lucene-core-7.3.1.jar:7.3.1 ae0705edb59eaa567fe13ed3a222fdadc7153680 - caomanhdat - 2018-05-09 09:27:24]
at org.apache.lucene.codecs.blocktree.BlockTreeTermsWriter.write(BlockTreeTermsWriter.java:343) ~[lucene-core-7.3.1.jar:7.3.1 ae0705edb59eaa567fe13ed3a222fdadc7153680 - caomanhdat - 2018-05-09 09:27:24]
at org.apache.lucene.codecs.FieldsConsumer.merge(FieldsConsumer.java:105) ~[lucene-core-7.3.1.jar:7.3.1 ae0705edb59eaa567fe13ed3a222fdadc7153680 - caomanhdat - 2018-05-09 09:27:24]
at org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsWriter.merge(PerFieldPostingsFormat.java:164) ~[lucene-core-7.3.1.jar:7.3.1 ae0705edb59eaa567fe13ed3a222fdadc7153680 - caomanhdat - 2018-05-09 09:27:24]
at org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:230) ~[lucene-core-7.3.1.jar:7.3.1 ae0705edb59eaa567fe13ed3a222fda
dc7153680 - caomanhdat - 2018-05-09 09:27:24]
at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:115) ~[lucene-core-7.3.1.jar:7.3.1 ae0705edb59eaa567fe13ed3a222fdadc7153680 - caomanhdat - 2018-05-09 09:27:24]
at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4443) ~[lucene-core-7.3.1.jar:7.3.1 ae0705edb59eaa567fe13ed3a222fdadc7153680 - caomanhdat - 2018-05-09 09:27:24]
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:4083) ~[lucene-core-7.3.1.jar:7.3.1 ae0705edb59eaa567fe13ed3a222fdadc7153680 - caomanhdat - 2018-05-09 09:27:24]
at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:624) ~[lucene-core-7.3.1.jar:7.3.1 ae0705edb59eaa567fe13ed3a222fdadc7153680 - caomanhdat - 2018-05-09 09:27:24]
at org.elasticsearch.index.engine.ElasticsearchConcurrentMergeScheduler.doMerge(ElasticsearchConcurrentMergeScheduler.java:99) ~[elasticsearch-6.3.2.jar:6.3.2]
at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:661) ~[lucene-core-7.3.1.jar:7.3.1 ae0705edb59eaa567fe13ed3a222fdadc7153680 - caomanhdat - 2018-05-09 09:27:24]

User包含int id,String name,int age

1.RocketMQ的Topic支持设置读写队列数，用于动态扩缩容， 而Kafka支持扩容，而不支持缩容

在JVM的堆内存中，新生代（Young Generation）被划分为三个部分：Eden区、Survivor 0区（S0）和Survivor 1区（S1）。S0和S1通常被称为幸存者区（Survivor Spaces）。幸存者区的存在主要是为了解决对象在经历一次或多次Minor GC后仍然存活的问题。

当Minor GC发生时，JVM首先回收Eden区中的短暂对象。在这个过程中，仍然存活的对象会被移动到一个幸存者区（例如S0），此时S0称为"to-space"，而另一个空的幸存者区（S1）称为"from-space"。在下一次Minor GC时，JVM将会回收Eden区以及上一轮GC后变为"from-space"的幸存者区（这里是S0）。在这次GC过程中仍然存活的对象将被移动到另一个幸存者区（这里是S1），此时S1变为"to-space"，而S0变为"from-space"。

幸存者区的设计有以下优点：

1. 减少内存碎片：在对象移动过程中，JVM会对存活对象进行整理，避免内存碎片的产生。

2. 年龄阈值：JVM可以跟踪对象在幸存者区的生命周期。当一个对象在幸存者区中多次GC后仍然存活，JVM会认为这个对象可能是长期存活的，并将其提升到老年代（Old Generation）以减少新生代中的Minor GC操作。

3. 动态调整：使用两个幸存者区可以在每次GC时动态调整存活对象的分配，提高内存利用率。

总之，两个幸存者区S0和S1的设计，有助于提高内存利用率、减少内存碎片和有效地管理短暂存活和长期存活的对象。

Environment

Flink version: 1.14.4
Flink on Kubernetes Application mode

Program args:

--source.hostname xxx.xxx.xxx.xxx
--source.port 3306
--source.database db_test
--source.table yzhou_tb_flink_job
--source.username db_test_rw
--source.password DB#Test2xxxxx
--source.startup.mode INITIAL
--sink.url jdbc:mysql://1xxx.xxx.xxx.xxx:3306/db_test?useUnicode=true&characterEncoding=utf8&allowMultiQueries=true&useSSL=false&serverTimezone=Asia/Shanghai
--sink.username db_test_rw
--sink.password DB#Test2xxxxx
--sink.table yzhou_tb_flink_job02

当作业运行后, JobManager 的logs 发现，$internal.application.program-args 参数从 “#”的位置被截断
以下是部分日志:

2022-04-18 15:44:37,870 INFO org.apache.flink.configuration.GlobalConfiguration [] - Loading configuration property: high-availability.storageDir, s3://fmflinkha/
2022-04-18 15:44:37,871 INFO org.apache.flink.configuration.GlobalConfiguration [] - Loading configuration property: s3.endpoint, s3-xxx.xxx.com
2022-04-18 15:44:37,871 INFO org.apache.flink.configuration.GlobalConfiguration [] - Loading configuration property: $internal.application.program-args, --source.hostname;xx.xx.xx.xx;--source.port;3306;--source.database;db_test;--source.table;yzhou_tb_flink_job;--source.username;db_test_rw;--source.password;DB

已知producer.send()方法底层是异步的,kafka发送消息时候内部会有一个消息累加器
那么kafka生产者同步发送消息时候经过消息累加器发送给broker还是直接发送给broker ？是怎样的流程
如果是经过累加器批量发送的话生产者如何得到当前发送的消息的结果

···
kafkaSourceBuilder.setProperty("sasl.mechanism", "SCRAM-SHA-256")
.setProperty("security.protocol", "SASL_PLAINTEXT")
.setProperty("sasl.jaas.config",
String.format("org.apache.kafka.common.security.scram.ScramLoginModule required username='%s' password='%s';", aclAccount, aclPassword));
···
问题解决方法：
sasl.jaas.config 配置项，别忘记最后的 ”;“

https://github.com/xinzhuxiansheng/blog-notes/blob/8d91132ec4e89824a4ea4ee439083d624f13eb01/Java/JVM/03-JVM%E6%9F%A5%E7%9C%8B%E7%94%A8%E7%9A%84%E6%98%AF%E5%93%AA%E4%B8%AA%E5%9E%83%E5%9C%BE%E6%94%B6%E9%9B%86%E5%99%A8.md

https://github.com/xinzhuxiansheng/blog-notes/blob/master/Mybatis/02-Mapper%E6%8E%A5%E5%8F%A3%E7%9A%84%E5%8A%A8%E6%80%81%E4%BB%A3%E7%90%86%E5%AE%9E%E7%8E%B0%E9%80%BB%E8%BE%91.md

环境：
JDK 11

异常描述

2022-05-05 17:56:16  [ SpringApplication.java:646 ] - [ INFO ]  The following 1 profile is active: "local"
2022-05-05 17:56:18  [ StartupInfoLogger.java:61 ] - [ INFO ]  Started ConfigTest in 2.652 seconds (JVM running for 5.239)
2022-05-05 17:56:19  [ ConfigTest.java:26 ] - [ INFO ]  job name: {flink.job.name}
2022-05-05 17:56:19,079 SpringApplicationShutdownHook WARN Unable to register Log4j shutdown hook because JVM is shutting down. Using SimpleLogger
Exception in thread "SpringApplicationShutdownHook" java.lang.ClassCastException: class org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to class org.apache.logging.log4j.core.LoggerContext (org.apache.logging.log4j.simple.SimpleLoggerContext and org.apache.logging.log4j.core.LoggerContext are in unnamed module of loader 'app')
	at org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.getLoggerContext(Log4J2LoggingSystem.java:401)
	at org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.lambda$getShutdownHandler$2(Log4J2LoggingSystem.java:376)
	at java.base/java.lang.Iterable.forEach(Iterable.java:75)
	at org.springframework.boot.SpringApplicationShutdownHook.run(SpringApplicationShutdownHook.java:116)
	at java.base/java.lang.Thread.run(Thread.java:834)
Disconnected from the target VM, address: '127.0.0.1:58216', transport: 'socket'

Process finished with exit code 0

问题解决方法：
将项目的log4j version 由 2.8.2升级到 2.17.2,就修复此问题

现象

Mac 测试没有问题，当服务部署在Linux后，测试后，容易出现线程阻塞

refer to https://www.jb51.net/article/232584.htm

A:

MySQL选择使用B+树而不是B树作为索引结构的原因主要有以下几点：

查询性能稳定：B+树的所有叶子节点都位于同一层，这意味着每次查找的时间复杂度都是相同的。而在B树中，数据可以存储在内部节点或叶子节点，导致查询性能波动。由于数据库系统对查询性能要求较高，因此B+树能提供更稳定的查询性能。

范围查询优势：B+树的叶子节点通过指针连接，便于进行范围查询。在执行范围查询时，只需找到范围的起始节点，然后顺序遍历叶子节点即可。而在B树中，由于数据可能分布在多个层次，范围查询性能较差。

磁盘I/O优化：数据库通常存储在磁盘上，磁盘I/O操作是影响数据库性能的关键因素。B+树的非叶子节点仅存储键值和子节点指针，不包含实际数据，因此每个非叶子节点可以存储更多的键值，从而降低树的高度，减少磁盘I/O次数。而B树的内部节点包含数据，导致树的高度增加，增加磁盘I/O次数。

更好的磁盘读取性能：由于B+树的叶子节点存储了所有数据，相邻的叶子节点在磁盘上通常是连续存储的。磁盘读取数据时，顺序读取速度远高于随机读取。B+树的结构有利于提高磁盘读取性能。而B树的数据分布在各个层次，可能导致更多的随机读取操作。

更适合外部存储：B+树更适合用于外部存储（如磁盘）的数据结构。由于B+树的非叶子节点仅存储键值和子节点指针，一个节点可以容纳更多的键值，这有助于减少树的高度和磁盘I/O操作。而B树的内部节点包含数据，增加了节点的大小，可能导致更多的磁盘I/O操作。

基于以上原因，MySQL选择使用B+树作为索引结构，以提供更好的查询性能、范围查询支持和磁盘I/O优化。

商城每天产生6千万订单数据，怎么设计方案(支持不同用户的检索,以及聚合分析这些数据)

refer: yifanzheng/cs-notes#43

ReentrantLock 是等待可中断的，当持有锁的线程长时间不释放锁的时候，等待中的线程可以选择放弃等待，转而处理其他的任务。

可再（重）入：它是表示当一个线程试图获取一个它已经获取的锁时，这个获取动作就自动成功，这是对锁获取粒度的一个概念，也就是锁的持有是以线程为单位而不是基于调用次数。

补充：ReentrantLock 基于 AQS 和 CAS 实现的，在加锁的时候通过 CAS 算法，将线程对象放到一个双向链表中，然后每次取出链表中的头节点，看这个节点是否和当前线程相等，是否相等比较的是线程的 ID。

QA

动态代理类创建过多

A:
https://github.com/xinzhuxiansheng/blog-notes/blob/master/MySQL/03-%E5%AF%BC%E8%87%B4MySQL%E8%87%AA%E5%A2%9E%E5%80%BC%E4%B8%8D%E8%BF%9E%E7%BB%AD%E7%9A%84%E5%8E%9F%E5%9B%A0.md

参考 apache/flink-cdc#825

1.消息队列如何进行负载？
2.消息发送如何实现高可用？
3.批量消息发送如何实现一致性？

待回复

在基于SASL/SCRAM动态认证部署的Kafka集群 broker节点启动后，发现 "__consumer_offsets" topic没有创建 ， 以前搭建低版本集群，没有刻意在意这个现象，是否自动创建，所以这里 引出一个issue "Kafka __consumer_offsets topic什么时候创建？"

TODO ? 通过源码解答这个问题

A：

如果一个MySQL表没有创建任何索引，那么该表不会为自定义索引创建 B+ 树。但需要注意的是，如果该表使用的是 InnoDB 存储引擎，那么它会自动创建一个聚簇索引。

InnoDB 存储引擎中的每个表都有一个聚簇索引。聚簇索引的键值（称为聚簇键）按以下优先级确定：

如果表定义了主键，那么聚簇键就是主键。
如果表没有定义主键，但有一个或多个唯一索引，则聚簇键为第一个非空唯一索引。
如果表没有主键和唯一索引，InnoDB 会为表生成一个名为 GEN_CLUST_INDEX 的隐藏聚簇索引，此索引基于一个称为“行ID”的内部生成的值。

所以，即使您没有为 InnoDB 表创建任何索引，它仍然会创建一个聚簇索引（使用 B+ 树结构），这是 InnoDB 存储引擎的设计特性。然而，如果使用的是 MyISAM 存储引擎，表中没有创建任何索引的话，就不会有 B+ 树。

A:
https://github.com/xinzhuxiansheng/blog-notes/blob/cba3f683a9969392b6c5c6bc7b89ec7935566b18/RocketMQ/%E5%85%A5%E9%97%A8%E7%AF%8707-%E4%BA%8B%E5%8A%A1%E6%B6%88%E6%81%AF.md

Caused by: java.util.concurrent.ExecutionException: org.apache.dubbo.remoting.TimeoutException: Waiting server-side response timeout by scan timer. start time: 2022-09-14 15:18:55.170, end time: 2022-09-14 15:19:55.179, client elapsed: 1 ms, server elapsed: 60008 ms, timeout: 60000 ms, request: Request [id=25, version=2.0.2, twoway=true, event=false, broken=false, data=null], channel: /xx.xx.145.148:52064 -> /xx.xx.155.80:20880
at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) ~[?:1.8.0_202]
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) ~[?:1.8.0_202]
at org.apache.dubbo.rpc.AsyncRpcResult.get(AsyncRpcResult.java:181) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.rpc.protocol.AbstractInvoker.waitForResultIfSync(AbstractInvoker.java:256) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.rpc.protocol.AbstractInvoker.invoke(AbstractInvoker.java:179) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.rpc.listener.ListenerInvokerWrapper.invoke(ListenerInvokerWrapper.java:78) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.rpc.cluster.support.AbstractClusterInvoker.invokeWithContext(AbstractClusterInvoker.java:300) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.rpc.cluster.support.FailoverClusterInvoker.doInvoke(FailoverClusterInvoker.java:79) ~[dubbo-3.0.4.jar!/:3.0.4]
... 65 more
Caused by: org.apache.dubbo.remoting.TimeoutException: Waiting server-side response timeout by scan timer. start time: 2022-09-14 15:18:55.170, end time: 2022-09-14 15:19:55.179, client elapsed: 1 ms, server elapsed: 60008 ms, timeout: 60000 ms, request: Request [id=25, version=2.0.2, twoway=true, event=false, broken=false, data=null], channel: /xx.xx.145.148:52064 -> /xx.xx.155.80:20880
at org.apache.dubbo.remoting.exchange.support.DefaultFuture.doReceived(DefaultFuture.java:212) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.remoting.exchange.support.DefaultFuture.received(DefaultFuture.java:176) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.remoting.exchange.support.DefaultFuture$TimeoutCheckTask.notifyTimeout(DefaultFuture.java:295) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.remoting.exchange.support.DefaultFuture$TimeoutCheckTask.lambda$run$0(DefaultFuture.java:282) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.common.threadpool.ThreadlessExecutor$RunnableWrapper.run(ThreadlessExecutor.java:196) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.common.threadpool.ThreadlessExecutor.waitAndDrain(ThreadlessExecutor.java:99) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.rpc.AsyncRpcResult.get(AsyncRpcResult.java:179) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.rpc.protocol.AbstractInvoker.waitForResultIfSync(AbstractInvoker.java:256) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.rpc.protocol.AbstractInvoker.invoke(AbstractInvoker.java:179) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.rpc.listener.ListenerInvokerWrapper.invoke(ListenerInvokerWrapper.java:78) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.rpc.cluster.support.AbstractClusterInvoker.invokeWithContext(AbstractClusterInvoker.java:300) ~[dubbo-3.0.4.jar!/:3.0.4]
at org.apache.dubbo.rpc.cluster.support.FailoverClusterInvoker.doInvoke(FailoverClusterInvoker.java:79) ~[dubbo-3.0.4.jar!/:3.0.4]

A：

1.B+树的磁盘读写代价更低 ，B+树的内部节点并没有指向关键字具体信息的指针，它仅存放目录数据，因此其内部节点相对B树更小，如果把所有同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多，一次性读入内存的需要查找的关键字也就越多，相对IO读写次数就降低了。

2.B+树的查询效率更加稳定, 由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，并且B+树深度在大量数据情况下，与B树结构存放要小很多

G1垃圾收集器在处理大对象时采用了一种称为"巨型对象"（Humongous Object）的机制。当一个对象的大小超过G1 Heap Region大小的一半时，它被认为是一个巨型对象。G1会使用特殊的处理方式来为巨型对象分配内存和进行回收。

巨型对象的分配过程如下：

G1首先尝试在老年代的连续空闲Region中分配巨型对象。这样做的目的是避免在年轻代中产生内存碎片和频繁的垃圾收集。
如果在老年代找不到足够的连续空闲Region来分配巨型对象，G1会尝试在年轻代的连续空闲Region中分配巨型对象。这种情况通常发生在老年代空间不足或内存碎片化时。
如果仍然无法找到足够的连续空闲Region来分配巨型对象，G1会触发一次Full GC，试图回收足够的空间来容纳巨型对象。如果Full GC后仍然无法分配巨型对象，那么将抛出OutOfMemoryError。

在回收巨型对象时，G1采用了一种称为"巨型对象收集"（Humongous Object Collection）的机制。巨型对象收集主要包括以下步骤：

G1会跟踪所有包含巨型对象的Region。
在并发标记周期结束后，G1会检查哪些巨型对象已经不再被引用，可以回收。
G1会在接下来的Mixed GC阶段中回收不再被引用的巨型对象所在的Region。

需要注意的是，巨型对象的回收可能会导致内存碎片化。如果发现G1在处理巨型对象时出现性能问题，可以尝试调整堆大小、Heap Region大小或其他相关参数以优化垃圾收集性能。

https://github.com/xinzhuxiansheng/blog-notes/blob/master/Mybatis/03-Insert%E6%95%B0%E6%8D%AE%E5%90%8E%E8%8E%B7%E5%8F%96%E4%B8%BB%E9%94%AEid.md

区别，1.7为什么会出现循环锁

在Java 8中，要查看G1垃圾收集器的Region设置，您可以使用以下方法：

使用-XX:+PrintFlagsFinal选项启动Java程序。这将在程序启动时打印所有JVM参数的最终值。在输出中，搜索G1HeapRegionSize参数。例如：

ruby

java -XX:+UseG1GC -XX:+PrintFlagsFinal -jar my_application.jar

在输出中，您将找到类似以下的行：

css

uintx G1HeapRegionSize := 1048576 {product}

这里，G1HeapRegionSize的值表示为字节。在这个例子中，它的值是1048576字节，也就是1MB。

使用jcmd工具。首先，找到您的Java进程的ID。然后，运行以下命令：

php

jcmd <process_id> VM.flags

这将打印出JVM参数。在输出中，找到G1HeapRegionSize参数。

请注意，如果您没有明确设置G1HeapRegionSize参数，JVM将根据堆大小自动选择一个合适的值。通常，G1会尝试创建2048个Region，Region大小在1MB到32MB之间。您可以使用-XX:G1HeapRegionSize=参数显式设置Region大小，其中是一个2的幂，单位为字节，例如-XX:G1HeapRegionSize=2m。

How to confirm wether the Kafaka loss the message and loss which one.

env
Spring Boot 2.6.7

在Spring Boot中 使用属性注入的方式，获取对应的值， @value 不需要属性的get(),set() ，而@ConfigurationProperties 必须使用。

QA:
@ConfigurationProperties 关注 JavaBeanBinder.addProperties(Method[] declaredMethods, Field[] declaredFields)

a==b ?
c==d ?

并且描述下，这样设计的好处