小菜鸟

Java javap 命令：解析字节码的利器

javap 是 JDK 自带的字节码分析工具，用于将 .class 文件反编译为人类可读的字节码指令、常量池、类结构等信息。它是理解 Java 代码底层实现、排查性能问题、学习 JVM 工作原理的重要工具。本文将详细介绍 javap 的用法、常用选项及输出内容解析。

javap 基本用法

语法格式

1

javap [选项] <class文件或类名>

• <class文件或类名>：可以是 .class 文件路径（如 Test.class），或类的全限定名（如 com.example.Test，需确保类在类路径下）。

常用选项

javap 提供多个选项，用于控制输出内容的详细程度，核心选项如下：

javap 输出内容解析

以示例类 TestString.class 为例，使用 javap -v TestString.class 输出的内容可分为以下几个核心部分：

类基本信息

输出开头显示类的版本、访问标志等基础信息：

Java OOM（内存溢出）问题全面解决方案

内存溢出（OOM，OutOfMemoryError）是 Java 应用中最棘手的问题之一，通常表现为程序突然崩溃并抛出 java.lang.OutOfMemoryError 异常。解决 OOM 问题需要系统分析内存使用情况，区分内存泄漏与内存不足，并针对性优化。本文将详细介绍 OOM 的排查流程、分析方法及解决方案。

OOM 类型识别：定位问题源头

OOM 异常的具体信息能直接指示问题发生的内存区域，常见类型包括：

关键区分：内存泄漏 vs 内存溢出

• 内存泄漏：对象已无用但仍被 GC Roots 引用（如静态集合未清理、监听器未移除），导致无法回收，长期积累引发 OOM。
• 内存溢出：对象均为必要对象，但总内存需求超过堆 / 元空间上限（如处理超大数据集时堆设置过小）。

OOM 排查步骤

步骤 1：收集基础信息

Java 字节码文件（.class）：结构与内容详解

字节码文件（.class）是 Java 源码经 javac 编译后的中间产物，是 JVM 可识别的 “机器语言”。它包含类的版本信息、常量、字段、方法、接口等关键数据，是 JVM 实现 “一次编译，到处运行” 的核心载体。本文将详细解析字节码文件的结构、各部分含义及作用，帮助理解 Java 代码如何被 JVM 执行。

字节码文件的整体结构

字节码文件采用二进制格式存储，结构严格遵循 JVM 规范，整体定义如下（基于 JVM 规范）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

ClassFile {
    u4             magic;                     // 魔数（识别class文件）
    u2             minor_version;             // 副版本号
    u2             major_version;             // 主版本号
    u2             constant_pool_count;       // 常量池计数器
    cp_info        constant_pool[constant_pool_count-1]; // 常量池表
    u2             access_flags;              // 访问标识（类/接口的修饰符）
    u2             this_class;                // 类索引（当前类的全限定名）
    u2             super_class;               // 父类索引（父类的全限定名）
    u2             interfaces_count;          // 接口计数器
    u2             interfaces[interfaces_count]; // 接口索引集合
    u2             fields_count;              // 字段计数器
    field_info     fields[fields_count];      // 字段表（类的字段信息）
    u2             methods_count;             // 方法计数器
    method_info    methods[methods_count];    // 方法表（类的方法信息）
    u2             attributes_count;          // 属性计数器
    attribute_info attributes[attributes_count]; // 属性表（辅助信息）
}

其中，u1、u2、u4、u8 分别表示 1、2、4、8 字节的无符号整数，用于描述不同长度的数据。

字节码文件各部分详解

Spring Session 实现分布式 Session 详解：基于 Redis 的配置与原理

在分布式系统中，传统的单机 Session（存储在 Web 容器内存中）会因 “多节点间 Session 不共享” 导致问题（如用户登录后切换节点需重新登录）。Spring Session 提供了优雅的解决方案：通过 HttpServletRequest 包装（Wrapper） 重写 Session 操作逻辑，将 Session 存储到分布式存储（如 Redis、MongoDB）中，实现多节点 Session 共享。从 “核心原理→依赖配置→实战步骤→底层逻辑” 四个维度，彻底讲透 Spring Session 的实现与使用。

分布式 Session 核心痛点与 Spring Session 解决方案

1. 传统单机 Session 的问题

在分布式部署（如多 Tomcat 节点负载均衡）场景下，传统 Session 存在以下问题：

• Session 不共享：用户请求被负载均衡分发到不同节点，各节点内存中的 Session 独立，导致用户登录状态丢失；
• Session 持久化差：Session 存储在节点内存中，节点重启后 Session 丢失；
• 扩展性差：无法支持大规模集群，节点数量增加会导致 Session 同步成本升高。

2. Spring Session 的核心思路

Spring Session 不依赖 Web 容器的 Session 实现，而是通过以下机制实现分布式 Session：

1. 包装 HttpServletRequest：通过 HttpServletRequestWrapper 重写 getSession() 方法，将 Session 操作委托给自定义的 SessionRepository；
2. 分布式存储：SessionRepository 将 Session 数据存储到 Redis、MongoDB 等分布式存储中，而非节点内存；
3. 过滤器拦截请求：通过 DelegatingFilterProxy 拦截所有请求，将原生 HttpServletRequest 替换为包装后的对象，确保所有 Session 操作都走分布式逻辑。

环境准备：依赖与 Redis 配置

Spring Session 支持多种存储介质，本文以 Redis（最常用）为例，需先配置依赖和 Redis 连接。

1. 依赖配置（Maven）

以下是更稳定的版本组合（适配 Spring 4.x/5.x）：

JVM 方法区：类元数据的存储中心

方法区（Method Area）是 JVM 运行时数据区的重要组成部分，虽在逻辑上属于堆的一部分，但在实现上通常被视为独立于堆的内存区域。它主要用于存储类的元数据、常量、静态变量等关键信息，是支撑 Java 反射、动态加载等特性的核心区域。本文将详细解析方法区的演变、存储内容、垃圾回收及参数配置，帮助理解其在 JVM 中的作用。

方法区的基本特性

线程共享与生命周期

• 线程共享：方法区是所有线程共享的内存区域，存储的类信息、常量等被所有线程共同访问。
• 生命周期：随 JVM 实例启动而创建，随 JVM 退出而销毁，与 JVM 生命周期一致。

核心功能

方法区的核心作用是存储已被 JVM 加载的类的元数据及相关信息，包括：

• 类的结构信息（如类名、父类、接口）；
• 常量池（字面量、符号引用）；
• 静态变量；
• 方法的字节码、局部变量表结构等。

与堆的关系

• 逻辑上，方法区属于堆的一部分（JVM 规范将其描述为 “堆的逻辑分区”）；
• 实现上，方法区被称为 “非堆”（Non-Heap），以区分于存储对象实例的堆，且垃圾回收策略与堆不同。

方法区的演变：从永久代到元空间

方法区的实现随 JDK 版本演变，核心变化是从 “永久代” 转向 “元空间”，解决了永久代内存限制的问题：

关键变化点：

1. JDK 7 的调整：
   • 将字符串常量池和静态变量从永久代移至堆中，永久代仅保留类元数据、运行时常量池等。
2. JDK 8 的重构：
   • 彻底移除永久代，改用元空间实现方法区；
   • 元空间存储类元数据、运行时常量池等，依赖本地内存（不占用 JVM 堆内存），默认无固定上限（可通过参数限制）。