传统的一个 Java 应用从代码编写到启动运行大致可以分为如下步骤： 首先，编写 .java 源代码程序。 然后，借助 javac 工具将 .java 文件翻译为 .class 的字节码，字节码是 Java 中非常重要的内容之一，正是因为它的出现，Java 才实现对底层环境的屏蔽，达到 Write once, run anywhere 的效果! 基于步骤 2 的 .class 文件会被打包成 jar 包或者 war 包进行部署执行，部署过程中通过 Java 虚拟机加载应用程序然后解释字节码运行业务逻辑。
最近面试问过很多候选人Java锁有关的知识，可以感受到的是，大家的理解基本都停留在“八股文”的阶段，实质上对Java的锁以及多线程的同步机制这种底层原理，理解的不是很好。网上这类文章已经很多了，但是看了下有好多文章都是相互抄的，而且都是过时的，典型的例如AQS里的addWaiter方法在JDK16里就没见到，或许代码进行了重构了。通过文章也梳理一下我一般看源代码的习惯是怎样的。 AQS全称是AbstractQueuedSynchronizer，首先他是一个抽象类，其次他使用了队列来进行排队，然后作用是用来做线程间的同步的。他是Java里所有锁的基础，包括CountDownLatch以及读写锁，可重入锁等等都是基于AQS实现的。我们从ReentrantLock入手来管中窥豹，大概得看看AQS的源代码。 首先你要了解的是使用方法，一个典型的ReentrantLock使用方法写在了这个类的注释里。
Java 应用在云计算时代面临“冷启动”慢、内存占用高、预热时间长等问题，无法很好的适应 Serverless 等云上部署模式，GraalVM 通过静态编译、打包等技术在很大程度上解决了这些问题，同时针对 GraalVM 的一些使用限制，Spring 和 Dubbo 等主流框架也都提供了相应的 AOT 解决方案。 本文我们将详细分析 Java 应用在云时代面临的挑战，GraalVM Native Image 是如何解决这些问题，GraalVM 的基本概念与工作原理，最后我们通过一个 Spring6 + Dubbo3 的微服务应用示例演示了如何将一个普通微服务应用进行静态化打包。
在线应用的诊断一直是日常维护中的难点和痛点，2018年下半年，Alibaba 开源了 java 应用诊断工具 arthas ，让 java 应用的诊断能力上了一个台阶。作为基础架构团队，我们自然也对它非常感兴趣。研究后发现，arthas 确实是一个非常优秀的 java 诊断工具，但是也存在一些不足。 一是 arthas 更像是一个工具，而不像一个产品。如果要使用它，首先要登录相关机器，然后在机器上下载 arthas，再执行一些命令来运行。这整个流程里，下载可能出现问题，运行 arthas 也需要具有目标进程相应的权限，还需要先看看对应进程id等等...这些确实只是一些小问题，但也可以选择让这些问题不存在，让整个使用过程更加流畅。 二是 arthas 缺少 web 界面。命令行界面用起来确实很酷，但不可否认在相当一部分情况下 web 界面更直观更友好，很多需要查文档的情况在 web 界面下都可以直接操作，降低了使用门槛。 三是 arthas 所有功能都针对单台机器，实际上很多时候我们需要考虑和观察整个应用的运行情况，需要一个应用级的视角。 四是 arthas 是一个独立的工具。
