Java 问题360度诊断

本文揭秘Java内存优化黑科技——String Deduplication。它可自动合并重复字符串，像内存"瘦身术"。无需改代码，开启-XX:+UseStringDeduplication即可。

从 thread dump 代码停止的位置到 JVM 的安全点Safepoint. 什么是JVM安全点, 哪些代码处是合适的安全点.

对的, 你没看错, 大量创建连接池, 连接是稳定的, 但是却导致线程暴涨. 为什么大量创建连接池会导致线程暴涨呢? 到底哪里出了问题?

开发Java应用的时候, 有时候我们想知道某个函数到底在哪里被调用的. 我们可以使用btrace, 有时候需要native 代码栈, 我们也可以使用 bpftrace. 本文实践如何使用bpftrac

大的软件公司里总是会出现这么一些做吃力不讨好工作的团队: 拆迁队. 他们的一段时期内的主要工作就是把原有的业务从旧的平台/框架, 迁移到新的平台/框架. 为什么? 因为软件行业里总是会出现新的框架,

最近开发人员查看他们应用的监控数据, 发现有个数据指标出现异常. 这个数据指标表示当前tomcat正在忙的线程数目, 之前这个指标一直在0~3徘徊, 可是最近一周, 它已经缓慢的到达了30多, 这引起

在诊断 Java 应用问题的时候, 经常需要做 heap dump. 因为 heap dump 就是一个资源宝库, 里面有各种运行时的内存数据, 结合源代码以及程序日志, 我们就能推断程序的运行状况,

通常情况下, 如果我们遇到某些异常, 都把出错异常栈打出来, 这样方便查看到底哪行代码出错了, 是怎么一层层调用到了这行代码.  可是有时候, 虽然我们明确写了打印出错异常栈, 可是偏偏日志里面却没有

线程相对来说是一个比较珍贵的资源, 创建和销毁它都会带来内存和CPU的开销. 所以, 尽量重用创建的线程, 尽量使用线程池. 可是我们却在 JDK 的代码没有遵循这个原则

有开发人员说: 最近上了新版本的代码, 经常看到处理某些请求的连接断掉, 从静态代码的分析来看, 找不出发生问题的根源. 本文记录了我们一步步查找, 发现问题最终原因的过程.

Java 9 之后出现这个错误: The package java.util is accessible from more than one module是怎么造成的?如何解决?

JDK目录里面自带了很多有用的诊断命令, 能帮我们了解java应用的内存, 线程, 启动参数, 统计信息等

大家经常听到内存泄漏, 那么线程泄漏是指什么呢? 线程泄漏是指 JVM 里面的线程越来越多, 而这些新创建的线程在初期被使用之后, 再也不被使用了, 然而也没有被销毁. 如何找出这段出错的代码呢?

诊断 Java 应用的过程中, 我们经常要去看线程的相关信息. 比如当前 JVM 有多少线程, 从启动到现在已经创建过多少线程, 线程的 CPU 使用率, 线程是不是发生了死锁等情况.