java on 文的超级笔记

spring 事务

Mon, 19 Oct 2026 00:00:00 +0000

为什么需要 Spring 事务管理？

数据库本身已经提供了事务机制，能够通过 COMMIT 和 ROLLBACK 等操作实现事务的提交与回滚。

但是，在 Java 项目中，如果直接使用 JDBC 管理数据库事务，开发者通常需要手动控制事务的开启、提交和回滚。

例如：

try {
    connection.setAutoCommit(false);

    // 创建订单
    // 扣减库存
    // 扣减余额

    connection.commit();
} catch (Exception e) {
    connection.rollback();
    throw new RuntimeException(e);
}

上述代码省略了数据库连接的获取、关闭等细节。

这种方式虽然可以实现事务管理，但存在几个问题：

重复代码较多：不同业务方法都需要编写事务开启、提交、回滚等逻辑。
业务逻辑与事务管理耦合：开发者不仅需要关注具体业务，还需要处理事务的生命周期。
事务管理容易出错：如果遗漏回滚操作，或者异常处理不当，就可能导致事务行为不符合预期。

因此，Spring 在底层事务能力之上提供了一套统一的事务管理机制，帮助开发者简化事务控制。

Spring 基础

Fri, 16 Oct 2026 00:00:00 +0000

Spring IoC

在传统的 Java 开发中，对象之间往往存在依赖关系。例如，一个 UserService 需要调用 UserDao 来完成数据库操作，最直接的方式就是在 UserService 内部通过 new 创建一个 UserDao 对象。

java基础

Sun, 11 Oct 2026 00:00:00 +0000

java集合

Tue, 06 Oct 2026 00:00:00 +0000

集合体系

Java 集合大体可以分成两套体系：Collection 和 Map。

类加载机制

Mon, 05 Oct 2026 00:00:00 +0000

类加载流程

一个 .class 文件真正被 JVM 使用之前，通常会经历：

加载
→ 验证
→ 准备
→ 解析
→ 初始化

加载阶段就是把 .class 文件读进 JVM。

问题排查

Mon, 05 Oct 2026 00:00:00 +0000

Full GC 频繁怎么排查

Full GC 频繁通常说明老年代或者元空间压力比较大，也可能是代码或参数配置导致 GC 退化。

排查时先看三个东西：

1
2
3

Full GC 发生频率
单次停顿时间
Full GC 之后内存是否明显下降

如果 Full GC 之后老年代占用明显下降，比如：

1
2

GC 前：90%
GC 后：30%

说明对象大部分其实是可以回收的，更像是对象创建太快、堆太小，或者大量对象过早晋升到了老年代。

这时可以继续看：

Young GC 是否过于频繁
对象晋升速度是否过快
新生代是否太小
是否存在大量大对象

如果 Full GC 之后老年代几乎不下降：

1
2

GC 前：90%
GC 后：85%

而且后面还在持续上涨，就要重点怀疑：

大量对象长期存活，甚至存在内存泄漏。

这时候通常需要导出 Heap Dump，分析：

1
2
3

哪些对象占用内存最多
哪些对象数量异常
这些对象为什么一直被 GC Roots 引用

另外还要关注 Full GC 的触发原因，比如：

GC

Sun, 04 Oct 2026 00:00:00 +0000

JVM 怎么判断对象是否可以回收

垃圾回收的第一步，是先判断哪些对象已经没有用了。

jvm内存结构

Sat, 03 Oct 2026 00:00:00 +0000

JVM整体内存结构

JVM 在运行 Java 程序时，会把运行过程中需要使用的内存划分成几个不同的区域，每个区域负责保存不同类型的数据。

从整体上看，可以先分成两类：线程私有区域和线程共享区域。

线程私有区域包括程序计数器、虚拟机栈和本地方法栈。每个线程都会有自己独立的一份，线程之间不会直接共用。

线程共享区域主要包括堆和方法区，也就是后面常说的元空间相关内容，这些区域会被多个线程共同访问。

JVM 内存

├── 线程私有
│   ├── 程序计数器
│   ├── 虚拟机栈
│   └── 本地方法栈
│
└── 线程共享
    ├── 堆
    └── 方法区 / 元空间

程序计数器用来记录当前线程执行到哪一条字节码指令。因为线程可能随时被切换出去，之后重新获得 CPU 时，需要知道应该从哪里继续执行，所以每个线程都必须有自己独立的程序计数器。

ThreadLocal

Fri, 02 Oct 2026 00:00:00 +0000

ThreadLocal 的作用

ThreadLocal 用来为每个线程保存一份独立的数据。

volatile+CAS

Fri, 02 Oct 2026 00:00:00 +0000

volatile 的作用

volatile 是 Java 提供的一种轻量级同步机制，主要解决两个问题：可见性和有序性。

ReentrantLock

Mon, 28 Sep 2026 00:00:00 +0000

问题

ReentrantLock 是什么？为什么已经有 synchronized 了还需要它？
ReentrantLock 和 synchronized 有什么区别？
ReentrantLock 为什么叫“可重入锁”？可重入是怎么实现的？
ReentrantLock 底层是怎么实现的？
- AQS 是什么
- state 表示什么
- exclusiveOwnerThread 表示什么
一个线程调用 lock() 以后，完整的加锁流程是什么？
- CAS 抢锁
- 抢锁失败以后怎么办
- 什么时候进入等待队列
- 什么时候阻塞线程
AQS 的等待队列是什么结构？
- CLH 队列
- head
- tail
- Node
等待线程是怎么被阻塞和唤醒的？
- LockSupport.park()
- LockSupport.unpark()
unlock() 的完整流程是什么？
- state 怎么减少
- 什么时候真正释放锁
- 怎么唤醒下一个线程
ReentrantLock 是怎么实现可重入的？
公平锁和非公平锁有什么区别？
- new ReentrantLock(true)
- 为什么默认是非公平锁
- 非公平锁为什么吞吐量通常更高
tryLock() 和 lock() 有什么区别？
- 立即失败
- 超时获取
- 适合什么场景
lockInterruptibly() 是什么？和 lock() 有什么区别？
Condition 是什么？为什么有了 wait/notify 还需要 Condition？
一个 ReentrantLock 为什么可以创建多个 Condition？
Condition.await() 和 signal() 的底层流程是什么？
- Condition Queue
- AQS Queue
- await 为什么会释放锁
- signal 为什么不是直接让线程继续执行
ReentrantLock 使用时为什么必须在 finally 里 unlock()？
ReentrantLock 会发生死锁吗？常见死锁场景有哪些？
ReentrantLock 和 synchronized 在性能上谁更好？
实际业务中什么时候更适合用 synchronized，什么时候更适合用 ReentrantLock？
如果让你手写一个简化版互斥锁，你会怎么基于 AQS 实现？

为什么已经有 synchronized 了，还需要 ReentrantLock？

ReentrantLock 本质上也是一种互斥锁，用来控制多个线程对共享资源的访问。

synchronized

Mon, 28 Sep 2026 00:00:00 +0000

synchronized 的三种使用方式

synchronized 主要有三种使用方式：修饰实例方法、修饰静态方法、修饰代码块。三者最核心的区别就在于：锁对象不同。

修饰实例方法时：

1
2

public synchronized void method() {
}

锁的是当前实例对象，也就是 this。

因此，如果两个线程操作的是同一个实例，它们会互斥；如果操作的是不同实例，因为锁对象不同，通常不会互相阻塞。

修饰静态方法时：

1
2

public static synchronized void method() {
}

锁的是当前类对应的 Class 对象，也就是：

线程池

Mon, 28 Sep 2026 00:00:00 +0000

结构化八股

为什么需要线程池

如果每个任务都直接 new Thread()，高并发时线程数量会不断增长。线程的创建、销毁、内存占用以及上下文切换都有成本，线程过多反而会降低系统整体效率。

因此线程池首先解决的是线程复用和并发控制：提前维护一批线程，任务来了就交给这些线程执行，任务结束后线程不销毁，而是继续处理后续任务。

固定线程不够怎么办

固定线程数虽然避免了线程无限增长，但如果任务突然增多，线程全部忙起来，剩余任务就需要有地方暂存。

于是线程池引入了 workQueue。当线程暂时处理不过来时，新任务先进入队列，等已有线程执行完当前任务后，再继续从队列中取任务。

队列也不能无限增长

任务队列解决了短时间流量突增的问题，但如果任务进入速度长期大于处理速度，队列就会不断积压。无界队列可能最终占满内存，即使没有 OOM，任务等待时间也会越来越长。

java on 文的超级笔记

spring 事务

为什么需要 Spring 事务管理？

Spring 基础

相关问题

一、Spring IoC 与 Bean 管理（8 题）

二、Spring AOP 与动态代理（5 题）

Spring IoC

java基础

相关问题

java集合

相关问题

集合体系

类加载机制

相关问题

类加载流程

问题排查

Full GC 频繁怎么排查

GC

相关问题

JVM 怎么判断对象是否可以回收

jvm内存结构

相关问题

JVM整体内存结构

ThreadLocal

相关问题

ThreadLocal 的作用

volatile+CAS

相关问题

volatile 的作用

ReentrantLock

问题

为什么已经有 synchronized 了，还需要 ReentrantLock？

synchronized

相关问题

synchronized 的三种使用方式

线程池

相关问题

结构化八股

为什么需要线程池

固定线程不够怎么办

队列也不能无限增长