在周志明的《深入理解java虚拟机》，2nd，p47中有一部分文字如果对象是一个java数组，那在对象投中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通java对象的元数据信息确定java对象的大小，但是从数组的元数据中却无法确定数组的大小。元数据即描述数据的数据，类似于mysql数据库中有单独存储了表信息和索引的表。由此考虑到整理的java内存分布图，想到类加载类信息加载到元空间里，

近期发现，Linux中vi的英文全称为Visual Interface。

例如，传的日期是 2023-10-08 却用 LocalDateTime 解析是不行的，应该使用 LocalDate，有一个比较好的办法，就是使用Unix时间戳传long类型的日期不会有这些问题，如果有时区，另外加上时区即可。如果有，在 filter 或 aop 层次看请求参数中的日期格式。不排除是请求参数格式与接收的类型冲突。确保日期格式、日期类型对应起来。首先一点，看对应的字段上是否有。

k8s中Service的各个port区别

k8s ingress注解

在 kafka 2.0.0 的 java sdk 中ProducerRecord 中类注释如下说明了 key 与分区编号的关系。

java bean验证 Jakarta Validation与hibernate-validator以及spring-boot-starter-validation区别

这样参数的顺序正好对应起来最后匹配 bootstrap 值的问题，例如项目中使用了 nacos 中的配置中心功能，很多参数不需要在项目中进行配置，在 nacos 中进行指定就可以，但是 nacos 中的配置参数与项目是隔离的。加载完文件转换为 Environment 中对应的值之后，接下来需要将对应的值与对应的配置类进行绑定，方便对应的组件取值处理接下来的操作。以迭代器中的值顺序为准与 cache

得知这个问题是日志级别设置错误了，在 curator 5.x 修复了这个问题，自己在试了 maven 仓库中从 5.0.0 开始的版本，从 5.2.0 中开始变成了 info。是 curator 组件的 EnsembleTracker 的 214 行日志错误。搜索引擎搜一下，看是否有人遇到过类似的问题。得知，是日志级别的问题，不是异常。

日常接触的项目里使用 gradle 构建的不多，但是很多开源的用了这个，项目需要下载对应的 gradel 安装包，对于下载默认访问的是 services.gradle.org，这个域名解析到了美国，鉴于国内网络问题，访问境外网络慢。至于 maven 加速地址，使用哪个无所谓，只要 jar 对应的 groupId、artifactId、version都能找到就可以。最后，为了加快 jar 的下载速度