Java图书管理系统的核心在于分层职责与数据一致性控制，而非堆砌功能；通过POJO建模、ConcurrentHashMap内存仓储、状态机借阅流程及MySQL行级锁与约束，确保库存不超卖、借阅关系准确、并发安全。
Java 图书管理系统不是靠堆功能实现的，而是靠分层职责和数据一致性控制住的。核心不在“能增删改查”，而在“改一条书目时借阅记录不能断、库存不能负、并发修改不冲突”。下面按真实开发节奏拆解关键环节。
用 Book 和 BorrowRecord 类建模，别急着加数据库
先写干净的 POJO，字段对齐业务语义，不是数据库字段。比如 Book 里要有 isbn（唯一标识）、stock（当前可借数量），但不要直接叫 book_count；BorrowRecord 必须含 borrowTime 和 returnTime（后者可为 null），否则无法判断是否逾期。
常见错误：把 Book 设计成带 ArrayList<BorrowRecord> 的聚合体——这会让单次查询拖慢整个系统，且违反单一职责。借阅关系必须由服务层协调，不是对象内嵌。
-
isbn字段用String，别用long或int，ISBN-13 含前缀“978”且可能带短横 -
stock初始化后禁止直接 public set，所有变更走decreaseStock()/increaseStock()方法，内部校验非负 - 两个类都重写
equals()和hashCode()，依据isbn判等（Book）或组合userId + isbn + borrowTime（BorrowRecord）
用 ConcurrentHashMap 模拟内存仓储，避开早期 JDBC 连接陷阱
初期不用 MySQL，用 ConcurrentHashMap<String, Book> 存书目，ConcurrentHashMap<String, List<BorrowRecord>> 存借阅关系（key 是 isbn）。这样能快速验证业务逻辑，且天然支持并发安全的 putIfAbsent、computeIfPresent 等操作。
立即学习“Java免费学习笔记（深入）”；
为什么不用 HashMap？因为管理员上架新书和用户借书可能同时发生，put() 不是原子操作，会导致覆盖或 NPE。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 上架新书用
books.putIfAbsent(isbn, new Book(...))，避免重复添加 - 借书时先
get()查库存，再用computeIfPresent(isbn, (k, v) -> { if (v.getStock() > 0) { v.decreaseStock(); return v; } else return v; })原子扣减 - 别在 map 里存
null值，get()返回 null 要立刻判空，否则后续调用getStock()抛NullPointerException
借书操作必须用状态机控制，不是简单 if-else
一次借书涉及三个状态检查：用户是否有未还书籍（按规则限借）、图书是否在库、用户是否已借过此书（防重复借同一本未还）。这些不能写成平行 if 判断，要用明确的状态流转。
public BorrowResult borrowBook(String userId, String isbn) {
Book book = bookStore.get(isbn);
if (book == null) return BorrowResult.FAIL_BOOK_NOT_FOUND;
<pre class='brush:java;toolbar:false;'>if (book.getStock() <= 0) return BorrowResult.FAIL_OUT_OF_STOCK;
List<BorrowRecord> userRecords = borrowRecordStore.get(userId);
if (userRecords != null && userRecords.stream()
.anyMatch(r -> r.getIsbn().equals(isbn) && r.getReturnTime() == null)) {
return BorrowResult.FAIL_ALREADY_BORROWED;
}
// 此处才真正扣库存、生成记录、存入
book.decreaseStock();
BorrowRecord record = new BorrowRecord(userId, isbn, LocalDateTime.now());
borrowRecordStore.computeIfAbsent(userId, k -> new CopyOnWriteArrayList<>()).add(record);
return BorrowResult.SUCCESS;}
注意：CopyOnWriteArrayList 用于用户借阅列表，因为读远多于写；而库存扣减必须在 computeIfPresent 块内完成，否则存在查到有库存 → 被别人借走 → 自己再扣的竞态漏洞。
迁移到 MySQL 时，stock 字段必须加 CHECK (stock >= 0) 和行级锁
上线前切库，最容易崩的是库存超卖。光靠 Java 层校验没用，数据库必须兜底。
- 建表时给
stock加约束：stock INT NOT NULL CHECK (stock >= 0)，插入或更新触发校验 - 借书 SQL 必须用
UPDATE books SET stock = stock - 1 WHERE isbn = ? AND stock > 0，并检查executeUpdate()返回值是否为 1 —— 返回 0 说明已被抢光 - 避免用
SELECT ... FOR UPDATE锁整张表，只在事务中对单行加锁，且事务粒度要小（只包 UPDATE + INSERT borrow_record）
真正难的不是写完功能，是当 5 个管理员同时上架同一本书、20 个学生秒抢热门教材时，系统不报错、不超卖、不丢记录。这些压力点，得在内存模型阶段就埋好钩子，而不是等连上数据库才想起加锁。
