九师兄

但是有没有思考，我们项目都改成jdk 17了。这里为什么还是jdk 1.8呢？这是因为debug模板的问题。在上一篇文章中，我们最后找到原因是Debug的时候设置的JDK问题。我们改成如下模板就好了，下次就不是默认的jdk 8了。最后我们改成如下才解决。

我们环境现在处于升级阶段，我们既要运行老的jdk 17版本，也要使用老的jdk1.8版本，为此我特意在本地安装了2套jdk环境，而且安装了2个IDEA，然后一套使用jdk 1.8 ，一套使用jdk 17,但是运行报错。我的jdk 1.7 环境装机如下，jdk 17 装机的时候使用的是msi包，好像不需要设置环境变量。这次我是解决后复现这个问题，再次查看版本信息以前全是jdk 17，现在javap的环境变了，奇怪。如果大家遇到同样的问题，那么Jdk的设置可以按照我的去设置能减少很大的问题。

为什么要有分布式事务？因为在微服务大规模运用下，我们往往一个操作需要多个微服务来完成，这就涉及分布式事务了。Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA和XA事务模式，为用户打造一站式的分布式解决方案。在seata下我们看看都有哪些角色，以及角色都有什么作用?seata下主要有3个角色，下面来分别介绍。

Keepalived是一个基于VRRP协议来实现的服务高可用方案。VRRP协议(虛拟路由冗余协议–Virtual Router Redundancy Protocol， 简称VRRP），是由IETF提出的解决局域网中配置静态网关出现单点失效现象的路由协议，1998年已推出正式的RFC2338协议标准。VRRP广泛应用在边缘网络中，它的设计目标是支持特定情况下IP数据流量失败转移不会引起混乱，允许主机使用单路由器，以及即使在实际第一跳路由器使用失败的情形下仍能够维护路由器间的连通性。

最近遇到一个问题，别人的一个程序，发现有一段代码要进行数据解析，字符串转java对象。代码中有这样的一解析，然后小数据量是没问题的，但是这一次出问题了，原因是这个json行数高达100万行，大概有8万个对象。本地调试的时候，代码会直接在这一点卡死，一动不动的。然后本地查看内存的时候会嗖一下内存从150M，上升到2.5G。由此可见大json解析是多么耗费内存。而且程序运行起来会不停的full GC。

如果程序中出现了OOM问题，我们一般情况下是使用arthas监控，然后加上jmap获取堆栈信息，以及线程信息，然后dump出相关信息后进行分析。arthas的使用这里暂时不分析，我们这里假设我们dump出来一个文件。下面看看怎么分析这个文件。这里学到一个小技巧，在arthas中我们也能dump文件，而且更加方便我们导出文件后，可以直接使用本地的vm分析工具，导入导入之后可以看到一个概要信息。

事情是这样的，我们使用的是FastJSON，但是使用了第三方框架，第三方框架使用的是jackson，然后导致我们传参我们这边看着不是空的，但是对方那边一直是空的。20230929今天遇到一个FastJSON解析，使用引用导致解析错误的问题。我们可以禁用fastjson的引用关系就好了，此时再次运行两者就都有了。这个运行起来测试如下。

在以前开发中，我们经常使用IP直接连接数据库，这种是经常做的，但是为啥京东开发要禁用IP直连呢？但是稍微成熟的设计是使用域名或者一个字符串来连接为什么开发者建议使用下面这种呢，这是涉及开发中解耦的问题。如果我们使用ip直接连接，那么就是强耦合，假设我们把线下开发的时候写了一个ip，然后测试完毕打包到线上，那么还需要强制修改数据库连接地址。还比如你的线上环境好几个app，然后都连接了一个数据库，然后现在因为老的数据库性能不好，要切换新买机器的数据库，那么就需要修改配置，也是很麻烦的。

线性探测法在处理冲突时需要逐个尝试下一个位置，直到找到一个空槽或者遍历完整个哈希表。这种逐步探测的方式可能导致性能下降，特别是当哈希表的负载因子较高时，冲突的概率增加，探测的开销也会增加，导致平均查找时间的增加。线性探测法容易产生聚集效应，即相同哈希值的元素在哈希表中聚集在一起。当出现大量冲突时，这些聚集的元素会形成一个线性的连续区域，这会导致哈希表的性能下降，因为查找时需要逐个探测这些相邻的元素。线性探测法在删除元素时存在问题。当要删除一个元素时，需要保持哈希表的连续性，即不能留下空洞（未被使用的槽位）

本章节主要讲解分布式锁的实现需要考虑哪些因素？锁必须是互斥的锁必须是可重入的锁必须是安全的锁最重要的就是要必须是互斥的，如果不是互斥的，那么将没有意义。那我们接着来思考一下，如果让我们去实现一个分布式锁，我们应该要满足那些条件呢？我们这个分布式锁可能会有很多的服务器来获取，所以我们一定要能够高性能的获取和释放;不能因为某一个分布式锁获取的服务不可用，导致所有服务都拿不到或释放锁，所以要满足高可用要求；

综上所述，当过度使用 volatile 关键字时，可能会导致内存开销、可见性问题和死循环等问题。要解决这些问题，可以使用更轻量级的同步机制、锁或者重新评估需求，选择更合适的解决方案。通过以上步骤，可以帮助你排查过度使用 volatile 导致的问题。重点在于审查代码、分析并发操作、检查可见性问题、使用调试工具和进行综合性的测试。怎么排查这样的问题？

当一个对象被线程获取到锁后，JVM会在对象头中的一部分空间存储线程ID，表示该对象处于偏向锁状态。此时，其他线程在获取该对象的锁时，不需要进行任何的同步操作，而是直接检查对象头中的线程ID是否与当前线程ID相同，如果相同，就表示该线程已经获取到了对象的锁，可以直接执行相关代码，避免了互斥同步的开销。，用于标记某个线程获取到了对象的锁，并且用于提供快速路径的访问。当其他线程尝试获取该对象的锁时，会触发偏向锁的撤销，重新回到无锁或者轻量级锁的状态，进而再进行竞争。，但是从来没考虑加在的是哪个对象的头上？

该方法本质上是不安全的。使用Thread.stop停止一个线程会导致它解锁所有已锁定的监视器（这是因为未经检查的ThreadDeath异常在堆栈中传播的自然结果）。如果这些监视器之前保护的任何对象处于不一致状态，损坏的对象将对其他线程可见，可能导致任意行为。如果目标线程等待长时间（例如，在条件变量上等待），应使用interrupt方法中断等待。以前我一直知道，java Thread Stop是被废弃的方法，只知道有问题，是直接关闭线程，会影响业务，但是究竟为什么废弃，却没有深入思考过。我们看下面这个案例。

从手动重试，到使用 Spring AOP 自己动手实现，再到站在巨人肩上使用特别优秀的开源实现 Spring Retry 和 Google guava-retrying，经过对各种重试实现方式的介绍，可以看到以上几种方式基本上已经满足大部分场景的需要：如果是基于 Spring 的项目，使用 Spring Retry 的注解方式已经可以解决大部分问题如果项目没有使用 Spring 相关框架，则适合使用 Google guava-retrying：自成体系，使用起来更加灵活强大。

然后猛然发现自己已经经常用的东西，源码都没看过。线程，有时被称为轻量级进程(Lightweight Process，LWP），是程序执行流的最小单元。一个标准的线程由线程ID，当前指令指针(PC），寄存器集合和堆栈组成。另外，线程是进程中的一个实体，是被系统独立调度和分派的基本单位，线程自己不拥有系统资源，只拥有一点儿在运行中必不可少的资源，但它可与同属一个进程的其它线程共享进程所拥有的全部资源。，同一进程中的多个线程之间可以并发执行。由于线程之间的相互制约，致使线程在运行中呈现出间断性。

在hashMap的put方法中是通过key的hash值和数组的长度取模计算得到的这样一个数组的位置，而在绝大部分情况下，N的值一般小于2的16次方，也是就是25536，所以也就意味着i的值始终是使用hash值的低16位与(n-1)进行取模运算，这是由与运算符的一个特征决定的，这样的话就会造成散列度不高，导致大量的key集中存储在一个固定的几个数组位置上，很显然会影响数组的查询性能。这样做的好处是，即使原始哈希码的分布不均匀，通过混合高位和低位的信息，可以增加最终的散列均匀性，减少哈希冲突的概率。

AQS实现中，等待队列的头部节点是持有锁资源或与锁相关的条件的节点，而后续节点是等待获取资源的节点。由于新加入的节点总是在链表的末尾，所以从后往前查找可以快速定位到最新的等待节点，避免了不必要的遍历。存储在双向链表中的任意一个位置的线程。都有可能出现线程中断导致这个线程从队列中移除，如果从前往后找，那么在并发场景下就可能出现一个空节点的问题，导致无法实现有效的线程唤醒，出现死锁的问题。这是因为在AQS中，等待队列是以双向链表的形式组织的，新加入等待队列的节点都是插入到链表的尾部。

同时，可重入锁的性能相对于内置的synchronized关键字较好，但使用时需要手动进行锁的获取和释放，因此需要更加仔细地管理锁的使用。在运行的某个函数和代码，因为抢占资源或者中断导致这个资源或者代码，运行过程中被中断了，那么等到中断的程序执行完成以后，重新进入到这个函数的代码中，再次运行的时候，并且运行的结果不会发生改变，那么这个函数或者代码就是可重入的。所谓可重入锁就是一个线程抢占了互斥锁的资源，在锁释放之前再去竞争同一把锁的情况，不需要等待，只需要去记录重试次数。今天遇到一个锁的问题，

但需要注意的是，对于简单的应用程序或连接数较少的场景，select仍然是一个有效的选择，并且具有更好的可移植性。select和epoll都是用于I/O多路复用的机制，用于管理并发的网络连接，它们可以让一个线程去监听多个文件描述符的IO事件或者连接事件，只要其中任何一个或者多个文件描述符就绪，就会触发阻塞唤醒，使得应用程序可以直接进行数据的读取或者写入。select是基干轮询的机和。一直到找到就绪的文件描达符，而epoll是基于事件通知机制，他只需要遍历当前就绪的文件描述符集合，大大减少了遍历的次数和开销。

而且在java中类的技能关系的设计 更多的是考虑共性能力的抽象，从而去提高代码的重用性和扩展性，而动态代理就是在做这样一件事情，它封装了动态代理的生成抽象逻辑，以及判断一个类是不是动态代理，以及其他相关的逻辑，那么我们把这些抽象的公共逻辑放到一个父类里面，也是一个正常的思路。在java中动态代理是通过调用Proxy.newProxyInstance()来实现的，但是却需要传入被动态代理的一个接口类，之所以要传入接口而不能传入类，还是取决于JDK动态代理的一个底层实现。

由于这三个指令并不是原子性的，按照重排序的第一个规则： 在不影响单线程执行结果的情况下，两个不存在依赖关系的指令是允许重排序的，也就是说不一定按照我们代码写的顺序来执行 ，这样就可能导致其他线程获取到一个不完整的对象。总结而言，将单例对象声明为volatile，可以解决DCL中的潜在线程安全问题，确保在多线程环境中正确且安全地获取到完全初始化的单例实例。在多线程环境中，由于指令重排序的优化，可能会导致某个线程在访问未完全初始化的单例对象时获取到一个不完整的实例。需要将单例对象声明为volatile的。

1.wait()方法：在Java中，wait()方法是Object类中的一个方法，用于线程间的同步和通信。当一个线程调用对象的wait()方法时，它会释放该对象的锁，并进入等待状态，直到其他线程调用相同对象的notify()或notifyAll()方法来通知等待的线程。。当等待的线程被通知后，它必须重新竞争锁才能继续执行。2.sleep()方法：在Java中，sleep()方法是Thread类提供的一个静态方法，用于使当前线程暂停执行一段指定的时间。。sleep()方法并不涉及锁的释放。

它可以是一个主动等待的状态，即进程或线程自己决定等待，也可以是被动等待的状态，即受到其他进程或线程的通知后等待。在等待状态下，进程或线程不会消耗CPU资源。表示进程或线程由于某种原因而无法继续执行，它可能在等待某个事件发生或等待某个资源变得可用。因此，"Blocked"通常用于描述进程或线程被动地等待某个事件或资源的情况，而"Waiting"通常用于描述进程或线程主动等待其他进程或线程的情况。"Blocked"和"Waiting"都是与进程或线程状态相关的术语，描述了它们在执行过程中的不同状态。

今天用Https远程调用，然后报错Unrecognized SSL message, plaintext connection。详情错误如下大概得调用逻辑如下这个异常通常在使用HTTPS时出现，可能是由于网络问题或SSL证书配置不正确导致的。建议按照以下步骤进行排查和解决：检查网络连接：确保网络连接正常，并且没有任何中断或代理问题。如果可能，请尝试在其他网络环境下运行代码，然后观察是否仍然出现相同的异常。检查SSL证书配置：确保所使用的SSL证书是正确配置的，并且与远程服务器的证书匹配。

虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。

本章主要讲解aviator临界值的问题，下面将用几个案例来说明这种特殊的情况。

不知道大家有没有遇到这样一直情况，我们去看GC日志的时候，看到很多System GC 触发的Full GC。但是我们去找我们代码的时候，发现我们没有调用System.gc()。这种情况就可能是堆外内存使用到了一定的量，达到了一些阈值，然后触发了System.gc()。这里提到的内存主要是java里面的DirectByteBuffer对象关联的那部分内存。和这个有关的主要是MaxDirectMemorySize这个参数。。

下面是jvm 线程栈的一些设置，简单的了解一下。

JVM 参数 CodeCache Size 主要是存储java虚拟机动态生成的一些代码。动态生成的代码比较多，比如字节码操作，或者其他动态生成，但是最多的是JIT热编译后的代码，java之所以快，是因为随着时间的推移，大部分热点代码会被编译成机器码来执行。：ReservedCodeCacheSize 是设置 CodeCache 的最大内存值，默认为 48M。如果启用了分层编译，默认值为 240M。同时，ReservedCodeCacheSize 的上限是不能超过 2G 的。

本章我们主要讲解如何定位线上的OOM的问题。

假设大对象最后会晋升老年代，而新生代是基于复制算法来回收垃圾的，由两个Survivor区域配合完成复制算法，如果新生代中出现大对象且能屡次躲过GC，那这个对象就会在两个Survivor区域中来回复制，直至最后升入老年代，而大对象在内存里来回复制移动，就会消耗更多的时间。假设大对象最后不会晋升老年代，新生代空间是有限的，在新生代里的对象大部分都是朝生夕死的，如果让一个大对象占据了新生代空间，那么相比起正常的对象被分配在新生代，大对象无疑会让新生代GC提早发生。

JSqlParse的总体代码量不大，结构也很简单，其项目整体结构图如下：包含表达式相关的类和接口，可以简单看做sql解析后的组成对象之一。如果需要对sql进行一些更改变换，基本都会涉及到这个包。JSqlParse最核心的包，这个包里的类实现了sql的解析，进而我们才可以对解析后的sql(“java类”)做各种自定义处理。虽然这个包是最核心的包，但如果纯粹从使用角度上来说可以不必太在意它，除非我们想深入了解sql解析的过程。

这个东西 不重要，因为我基本不会使用，了解一下即可。

但是在今天这个场景下，经过我的检查，确认 java.lang.NullPointerException 不是由 log.error(e) 打印出，那是哪里打印出的呢？即验证了上述的代码，执行到一定次数后，JVM 会将异常替换为预构建的异常，导致打印出的异常信息中不含栈帧，确认该问题原因后，我在 JVM 配置选项中加上了。我们的flink程序，经常运行很久，可能运行很多天后发现报错了，错误不是致命错误的时候，偶然我发现日志里面打印了很多异常信息，但是却没有异常栈，如下。JVM 中关于这部分优化的源码位于。

可以知道我们如果在IDEA中用到的类改变，那么IDEA会把相关的类，也重新编译一下，但是如果你的类是服务器上的，你如果直接替换包，或者类，那么引用他的类是不生效的。我们先反编译两个类看看，可以看到Constants类生效了，但是ConstantsUse类没有生效，里面还是修改后。为什么修改没有生效？是 Constants 类的问题，还是 ConstantsUse 类的问题？看到这里，原因也就明确了，常量变量会被编译进那些引用它们的类中。先看下面这个实验，我们先构建了一个常量类。

在所有的单例实现方式中，枚举是一种在代码写法上最简单的方式，之所以代码十分简洁，是因为Java给我们提供了enum关键字，我们便可以很方便的声明一个枚举类型，而不需要关心其初始化过程中的线程安全问题，因为枚举类在被虚拟机加载的时候会保证线程安全的被初始化。除此之外，在序列化方面，Java中有明确规定，枚举的序列化和反序列化是有特殊定制的。这就可以避免反序列化过程中由于反射而导致的单例被破坏问题。

在涉及到序列化的场景时，要格外注意他对单例的破坏。

1、如果一个类想被序列化，需要实现Serializable接口。否则将抛出异常，这是因为，在序列化操作过程中会对类型进行检查，要求被序列化的类必须属于Enum、Array和Serializable类型其中的任何一种。2、在变量声明前加上该关键字，可以阻止该变量被序列化到文件中。3、在类中增加writeObject 和 readObject 方法可以实现自定义序列化策略。

Apache Commons Collections是Apache Commons的组件，该漏洞的问题主要出现在org.apache.commons.collections.Transformer接口上。在Apache commons.collections中有一个InvokerTransformer实现了Transformer接口，主要作用为调用Java的反射机制来调用任意函数。影响组件版本：

jhat 可以读取由 jmap 或其他工具生成的 Java 堆转储快照（.hprof 文件），并将其转换为 HTML 形式，以便在 Web 浏览器中查看和分析。如果你正在使用的是 JDK 8 或更早的版本，jhat 仍然是一个非常有用的工具。但在使用时，应当注意安全性和性能的影响，因为 jhat 启动的 HTTP 服务器默认是未加密的，且可能消耗较多的资源。例如，如果你需要更大的堆内存来运行 jhat，可以使用 -J-Xmx512m。接下来，使用 jhat 分析生成的堆转储文件。第一步：生成堆转储文件。