J 博客

查看 HttpServletRequest 说明发现该类包含大量的内部状态和引用，比如输入流、会话信息、请求头等，直接序列化这些信息可能会形成循环引用或过于庞大，导致序列化过程占用过多内存甚至进入无限循环。初看也没发现什么问题，断点发现卡在了 new Gson().toJson(arg) ，断点调试跟进发现入参类型为 HttpServletRequest ，难道它不可直接打印？普通的http请求，导致堆内存直接溢出，看了下代码实现非常简单的一次DB查询且数据量也比较小，不可能导致内存溢出呢。

猜测是流读取导致的阻塞，回到开始看下 Process 的源码，发现文档说明中表示 Runtime.exec()创建的子进程公用父进程的流，父进程的stream buffer可能被打满导致子进程阻塞，从而永远无法返回。因为错误的流读取方式导致线程阻塞，虽然调整成先读取正常 input 流可以正常运行了，但是也存在全部输入为异常流，正常流无法读取的情况，所以最好的方式还是异步同时读取俩种流。输入缓冲区空：如果子进程需要从标准输入（stdin）读取数据，而父进程没有及时提供输入，子进程将阻塞，等待输入数据。

分布式跟踪的目标是收集和分析整个分布式系统中的请求路径和性能数据，以便开发人员可以更好地理解系统中的瓶颈和问题。它通过在应用程序的不同组件之间传递唯一的标识符（通常称为跟踪 ID）来实现这一点，以便跟踪一个请求在系统中的流动。上图中的 span_id 可以理解为应用标记ID，而 trace_id 是请求标记ID，贯穿整个请求且保持不变的。当一个请求进入分布式系统时，它被赋予一个唯一的跟踪 ID。

Springboot 执行 ES 单元测试时发生上述异常 , 看提示应该是因为使用了 ignore_throttled 过期参数导致的，但是我的查询并没有使用这个字段，那它是从哪里来的呢？先 debug 查看异常处代码 Response.assertWarningValue这段代码是从 es 请求的响应中提取告警信息，判断是否符合断言，该正则表达式分为三部分对比运行时异常信息发现，299 Elasticsearch-7.17.13-2b211dbb8bfdecaf7f5b44d356bdfe54b10

在JVM中，常见的线上问题包括但不限于内存泄露、CPU飙升、线程死锁、响应变慢、垃圾回收问题、类加载问题、网络问题、日志问题、配置文件问题和安全性问题。这些问题可能会导致系统性能下降、应用程序崩溃、功能无法正常使用等严重后果。为了确保应用程序的稳定运行，需要定期监控和调优JVM，及时发现和解决这些问题。

maven总结

logback异常问题分析