简介本资源是一份面向Java初学者与备考者的Core Java核心知识点精要笔记聚焦语言基础与关键机制助力快速构建扎实的编程底层认知。资料以单个PDF文件形式呈现1.64MB内容结构清晰、模块完整涵盖原码/反码/补码原理、char类型特性、移位与位运算符细节、switch与break/continue流程控制逻辑、构造方法与重载机制、this与super关键字用法、继承与多态实现、static/final/abstract等修饰符语义以及instanceof类型判断等高频考点。目录层级分明从二进制表示到面向对象核心概念逐层递进每节均含要点提炼与典型说明适合作为课堂笔记补充、面试前速查或自学知识图谱梳理。目前已有473人学习下载内容紧扣Java SE基础体系对夯实编码基本功、理解JVM底层逻辑及应对技术笔试具有明确支撑价值。1. 这份 CoreJava 笔记不是“速成宝典”而是你调试 NullPointerException 时翻得最勤的那页纸你有没有过这种经历线上服务突然抛出ConcurrentModificationException堆栈里只有一行ArrayList$Itr.checkForComodification(ArrayList.java:901)而你手边连个能快速定位modCount和expectedModCount关系的参考资料都没有或者在写泛型工具类时对着? super T和? extends T发呆半小时最后靠试错加注释硬凑出能编译的代码这份《CoreJava全套详细笔记资料.pdf》不是那种把 API 文档复制粘贴再加点颜色的“PPT式笔记”它是一份从 JVM 字节码层面反推语法设计、用真实调试断点截图佐证原理、甚至把String对象池里intern()调用前后内存地址变化都标出来的实战手札。它覆盖了从原码/补码底层表示第 5 页到ObjectInputStream反序列化安全校验第 46 页、从static初始化顺序陷阱第 11 页到ThreadLocal内存泄漏根因第 55 页的完整链条。适合两类人一是刚脱离“Hello World”阶段、正被final修饰符作用域和static块执行时机搞晕的新手二是需要快速回溯某个冷门机制比如ClassLoader.loadClass()的双亲委派中断条件的老手。它不教你“怎么写 Spring Boot”但当你写的自定义 ClassLoader 在热部署时莫名其妙加载失败翻到第 12 页“类加载的顺序”那一栏你会立刻明白问题出在哪——这才是它不可替代的价值。2. 从二进制补码到集合线程安全这份笔记如何用“可验证”的方式讲透 Java 核心机制2.1 原码/反码/补码为什么Integer.MIN_VALUE -Integer.MIN_VALUE是合法的很多教程把补码讲成“符号位不变其余位取反再加一”这没错但没解释清楚为什么这样设计。这份笔记在第 5 页直接给出 8 位二进制示例-1 的原码1000 0001 -1 的反码1111 1110 符号位 1 不变其余位取反 -1 的补码1111 1111 反码 1 -128 的原码1000 0000 -128 的反码1111 1111 -128 的补码0000 0000 溢出但这是设计使然关键点在于补码让加减法电路可以统一用加法器实现。笔记用(-1) 1验证1111 1111 0000 0001 0000 0000溢出位丢弃结果为 0完全正确。而Integer.MIN_VALUE即-128在 byte 范围的补码1000 0000取负时按规则计算1000 0000 → 0111 1111 → 1000 0000结果还是自己——这不是 bug是补码系统对称性的必然结果。笔记特别标注“JVM 规范明确要求整数溢出不抛异常此行为是Math.abs()在Integer.MIN_VALUE上返回负值的根源”。你在写数值校验逻辑时如果漏掉这个边界就会埋下静默错误。提示实际开发中不要依赖Math.abs(x)处理可能为MIN_VALUE的输入。安全写法是x Integer.MIN_VALUE ? Integer.MAX_VALUE : Math.abs(x)或直接用BigInteger.abs()。2.2 char 类型与 Unicode为什么char c \u0000;是合法的但c -1;编译报错第 6 页用一张表格厘清char的本质属性值说明存储大小2 字节16 bit固定长度非 UTF-8 变长数值范围0到65535即0x0000到0xFFFF无符号整数不是 -32768 ~ 32767字面量表示a,\u0041,\u20AC欧元符号单引号包裹支持 Unicode 转义隐式转换可自动转为int,long,float,double因其本质是无符号 16 位整数重点来了char c -1;报错不是因为“字符不能为负”而是因为-1是int类型字面量32 位有符号其值-1超出char的0~65535范围。而\uFFFF是合法的因为\uFFFF表示的是数值65535在范围内。笔记在旁边手写批注“char是无符号整数类型不是‘字符容器’——这是理解String底层char[]和codePointAt()差异的起点”。2.3 移位与位运算和在处理网络字节序时为何必须严格区分第 6 页的移位运算符部分没有停留在“算术右移逻辑右移”的定义而是给出一个 TCP/IP 协议解析的真实场景// 假设收到 4 字节数据0xFF, 0x80, 0x00, 0x00大端序 // 解析为有符号 int需保持符号位 int signedValue (bytes[0] 24) | ((bytes[1] 0xFF) 16) | ((bytes[2] 0xFF) 8) | (bytes[3] 0xFF); // 此时 signedValue -8388608正确 // 但如果误用 int wrong (bytes[0] 24) | ((bytes[1] 0xFF) 16) | ((bytes[2] 0xFF) 8) | (bytes[3] 0xFF); // bytes[0] 是 0xFF255左移 24 位后变成 0xFF000000 // 若用 会符号扩展但此处是位或关键在 bytes[0] 本身是 int // 所以必须先 0xFF 再移位否则高位被符号位污染。笔记强调byte到int的提升是符号扩展。byte b (byte)0xFF; int i b;结果i是-10xFFFFFFFF不是2550x000000FF。因此网络字节解析必须写b 0xFF强制转为无符号值。这个细节在 Netty 或 MINA 框架源码里高频出现笔记在第 6 页用红框标出“所有byte参与位运算前必先 0xFF”。2.4 集合框架的线程安全真相Vector的synchronized方法为何在高并发下反而更慢第 21 页对比ArrayList/Vector/Collections.synchronizedList()时笔记没停留在“Vector是线程安全的”这种模糊说法而是画出方法调用链// Vector.add() 源码逻辑简化 public synchronized boolean add(E e) { ensureCapacityInternal(size 1); // 同步块内 elementData[size] e; // 同步块内 return true; }问题在于整个方法体被一把锁保护。当多个线程同时调用add()和get(int index)时它们会互相阻塞——即使操作的是不同索引位置。笔记用一个实验数据佐证在 100 线程并发向Vector添加 1000 个元素的测试中平均耗时 128ms而用CopyOnWriteArrayList写时复制仅需 42ms读操作无锁。但笔记也冷静指出CopyOnWriteArrayList适用于“读多写少”场景若写操作频繁ArrayListReentrantLock分段锁才是更优解。它在第 21 页底部手绘了一个决策树读操作占比 95%→CopyOnWriteArrayList读写比例均衡→Collections.synchronizedList(new ArrayList())锁粒度比Vector更可控写操作密集且需强一致性→ConcurrentHashMap替代Map或自定义分段锁List3. 从this到super构造方法链与多态调用的“时间陷阱”3.1this()和super()必须是构造方法的第一条语句为什么 JVM 要强制这个顺序第 8 页和第 9 页用一个经典反例揭示本质class Parent { String name; Parent(String name) { this.name name; // ① System.out.println(Parent init: this.name); // ② } } class Child extends Parent { int age; Child(String name, int age) { // 错误不能在这里调用 super() // super(name); // 编译错误必须第一行 this.age age; // ③ super(name); // 编译错误super() 必须第一行 } }笔记解释JVM 在对象创建时内存分配和父类字段初始化必须在子类字段初始化之前完成。super()的作用是触发父类构造器确保父类状态如name在子类使用前已就绪。如果允许this.age age在super()之前那么③执行时this对象的父类部分name还是未初始化的垃圾值②中的this.name就会输出null或随机值。笔记在旁白写道“这不是语法糖是 JVM 对象模型的铁律——this指针只有在父类构造完成之后才真正‘活’过来”。3.2 多态中的instanceof与getClass()为什么obj instanceof String比obj.getClass() String.class更安全第 10 页对比这两个操作时笔记给出一个String子类假设存在的思考实验// 假设 Java 允许继承 String实际 final但用于说明原理 class MyString extends String { /* ... */ } MyString myStr new MyString(hello); System.out.println(myStr instanceof String); // true System.out.println(myStr.getClass() String.class); // falseinstanceof检查的是运行时类型是否为指定类型或其子类而getClass()返回的是最具体的类对象。笔记强调在框架开发中如 JSON 序列化器若用getClass() String.class判断字符串类型遇到MyString实例就会跳过字符串优化逻辑导致性能下降。而instanceof天然支持继承体系。但笔记也提醒一个坑instanceof对null安全返回false而getClass()对null会抛NullPointerException。所以安全写法是obj ! null obj instanceof String。3.3static块的执行时机为什么在类加载时初始化单例比static final更灵活第 11 页“类加载的顺序”中笔记用一个延迟初始化单例的案例class LazySingleton { private static LazySingleton instance; static { // ① static 块在类首次主动使用时执行如调用 getInstance() // ② 可以包含复杂逻辑读配置、连数据库、检查权限 System.out.println(Static block executed); instance new LazySingleton(); } private LazySingleton() {} // 私有构造 public static LazySingleton getInstance() { return instance; // ③ 简单返回无同步开销 } }对比public static final LazySingleton INSTANCE new LazySingleton();static final字段在类加载时立即初始化无法加入条件判断static块可以写if (Config.isProd()) { instance new ProdImpl(); } else { instance new MockImpl(); }但笔记也警告static块中若抛出异常该类将永久处于“初始化失败”状态后续任何使用都会抛NoClassDefFoundError。所以务必在static块中捕获所有异常并记录日志。4. 从String对象池到StringBuilder字符串操作的内存与性能黑匣子4.1String a hellovsString c new String(hello)对象池的“可见性”边界在哪第 16-17 页用 JVM 内存图解构字符串创建String a hello; // ① 从字符串常量池方法区获取若无则创建 String b hello; // ② 直接引用池中同一对象 → a b 为 true String c new String(hello); // ③ 在堆中新建对象内容同hello但地址不同 → a c 为 false String d c.intern(); // ④ 将 c 的内容放入常量池若无并返回池中引用 → a d 为 true笔记的关键洞见是intern()不是“把对象放进去”而是“把字符串内容注册到池并返回池中对应引用”。它在 JDK 7 后将常量池移到堆中所以intern()成本降低但仍有开销。笔记给出一个生产环境踩坑案例某日志模块对每条日志msg.intern()导致堆内存中常量池占用暴增 2GBGC 频繁。解决方案是仅对有限且重复率高的字符串如状态码SUCCESS,ERROR调用intern()而非所有日志消息。4.2StringBuffer与StringBuildersynchronized关键字在方法签名上的“重量级”代价第 17 页的对比表格直击本质特性StringBufferStringBuilder线程安全✅synchronized修饰所有公共方法❌ 无同步纯堆操作性能单线程比StringBuilder慢 15%~20%基准测试最快适用场景多线程共享的字符串构建如 Servlet 全局缓存绝大多数场景局部变量、方法内笔记用一段反编译字节码说明synchronized的开销// StringBuffer.append(String) 反编译后伪代码 public synchronized StringBuffer append(String str) { // ① 进入方法前monitorenter 指令获取对象锁 // ② 执行逻辑扩容、复制数组、追加字符 // ③ 方法结束前monitorexit 指令释放锁 return this; }而StringBuilder.append()没有这两条指令。笔记结论“除非你明确需要跨线程共享同一个StringBuilder实例否则永远选StringBuilder。StringBuffer是 Java 1.0 遗留的‘过度设计’”。4.3String不可变性的安全价值为什么HashMap的 key 必须是不可变对象第 16 页在String介绍末尾突然转向一个关键推论String的hashCode()在对象创建时就缓存private int hash;且因内容不可变哈希值永不改变。笔记画出HashMap插入流程put(key, value) → 1. 计算 key.hashCode() → 3214缓存→ 2. 定位桶位置 index 3214 (table.length-1) → 3. 将 Node 放入 table[index]如果String可变key被修改为newKey后hashCode()变为 5678但该Node仍留在index3214的桶里get(key)就再也找不到它——哈希表结构被破坏。笔记在此处加粗“String的不可变性是HashMap/HashSet正确性的基石不是为了‘优雅’是为了‘不死’”。5. 从try-catch-finally到try-with-resources异常处理的进化与陷阱5.1finally块中的return如何“吃掉”catch中抛出的异常第 34 页的异常处理章节用一个令人窒息的代码示例public static String readFile() { try { throw new IOException(read failed); } catch (IOException e) { System.out.println(Caught: e.getMessage()); throw new RuntimeException(wrap it, e); // ① 准备抛出 } finally { return from finally; // ② finally 中的 return 会压制上面的 throw } } // 调用结果返回 from finally且无任何异常抛出笔记解释JVM 规范规定finally块中若有return、throw或System.exit()它会终结当前方法的执行流覆盖try/catch中的任何异常或返回值。这是finally的“最高优先级”特性也是最易被忽视的玄学。解决方案只有两个方案一finally中绝不写return或throw只做资源清理方案二若必须返回先保存try/catch的结果再在finally后return。5.2try-with-resources的自动关闭原理AutoCloseable接口的close()方法为何必须幂等第 34 页对比传统try-catch-finally时笔记展示try-with-resources的字节码等价逻辑// 你的代码 try (FileInputStream fis new FileInputStream(a.txt)) { // do something } // 编译器自动插入fis.close() 在此处无论是否异常等价于FileInputStream fis null; try { fis new FileInputStream(a.txt); // do something } finally { if (fis ! null) { try { fis.close(); // ① 可能抛 IOException } catch (Throwable t) { // ② 如果此处抛异常会压制 try 块中的原始异常 // 所以 close() 必须尽量不抛异常 } } }笔记强调close()方法必须是幂等的多次调用无副作用且尽量避免抛异常。例如BufferedWriter.close()会先flush()若flush()失败则close()抛IOException——这就是为什么生产代码中常看到try (BufferedWriter writer new BufferedWriter(...)) { writer.write(data); } catch (IOException e) { // 处理 write 异常 } // close() 的异常被吞掉但业务逻辑已执行完毕5.3 自定义异常类的cause链为什么initCause()不能多次调用第 36 页的“自定义异常类”部分笔记给出标准模板public class BusinessException extends Exception { public BusinessException(String message) { super(message); } public BusinessException(String message, Throwable cause) { super(message, cause); // ① 正确通过父类构造器设置 cause // super(message); this.initCause(cause); // ② 错误initCause() 只能调用一次 } }initCause()内部有状态检查if (this.cause ! this) throw new IllegalStateException(Cant overwrite cause);。笔记提醒在框架中封装异常时如 DAO 层将SQLException包装为DataAccessException必须用带cause的构造器否则调用栈丢失getCause()返回null上游无法做精准异常分类。这是日志追踪和熔断降级的命脉。6. 从反射到ClassLoader动态加载的边界与安全红线6.1Class.forName()与ClassLoader.loadClass()静态初始化的“开关”由谁控制第 38 页的反射章节笔记用一个static块日志对比class TestClass { static { System.out.println(Static block executed!); } } // 场景1Class.forName(TestClass) Class? c1 Class.forName(TestClass); // 输出Static block executed! // 场景2ClassLoader.getSystemClassLoader().loadClass(TestClass) Class? c2 ClassLoader.getSystemClassLoader().loadClass(TestClass); // 无输出原因Class.forName(String)默认调用Class.forName(String, true, ClassLoader)第二个参数initializetrue表示触发类初始化执行static块而ClassLoader.loadClass()默认resolvefalse只加载不初始化。笔记警示“在热部署或插件系统中若用loadClass()加载类后直接newInstance()可能因static块未执行导致 NPE。此时应显式调用Class.forName(className, true, loader)”。6.2ClassLoader双亲委派的“破环”场景为什么 OSGi 和 Tomcat 要自定义类加载器第 12 页“触发类加载的几种情况”中笔记列出双亲委派的例外场景是否遵循双亲委派说明Class.forName()✅ 是默认走AppClassLoader→ExtClassLoader→BootstrapClassLoaderThread.currentThread().getContextClassLoader().loadClass()❌ 否上下文类加载器可被应用设置常用于 SPI 服务发现URLClassLoader加载 JAR✅ 是但可指定 parent 为null彻底切断委派笔记以 Tomcat 为例每个 WebApp 有自己的WebAppClassLoader其 parent 是SharedClassLoader非AppClassLoader从而实现应用间类隔离。而JDBC DriverManager通过Thread.currentThread().getContextClassLoader()加载驱动所以驱动 JAR 放在WEB-INF/lib下就能被找到——这是双亲委派被“绕过”的经典设计。笔记总结“双亲委派不是教条是隔离与共享的平衡术。破环的前提是清楚知道你要隔离什么、共享什么”。6.3 反射调用私有方法的安全检查setAccessible(true)在安全管理器下的失效风险第 37 页“反射需要用到的类”中笔记提到AccessibleObject.setAccessible(true)Field field SomeClass.class.getDeclaredField(privateField); field.setAccessible(true); // ① 绕过访问控制检查 Object value field.get(obj);但笔记加了一行小字警告“若 JVM 启动时设置了安全管理器-Djava.security.managersetAccessible(true)会抛SecurityException”。生产环境尤其金融、政务系统常启用安全管理器此时反射私有成员会失败。笔记建议的替代方案方案一用SuppressWarnings(removal)JDK 17标记但需评估风险方案二改用MethodHandleLookup.findSpecial()其权限检查更细粒度方案三根本上重构通过public接口暴露必要能力而非依赖反射。注意setAccessible(true)的“成功”不等于“安全”。它只是关闭了 JVM 的访问检查但若字段是final且已初始化修改其值仍可能导致 JVM 行为未定义如String.value被修改后hashCode()缓存失效。7. 从File到NIO.2文件操作的可靠性与跨平台陷阱7.1File类的delete()方法为何在 Windows 下经常失败第 40 页“File 构造方法”后笔记直指痛点File.delete()在 Windows 上返回false的常见原因文件被其他进程占用如 Excel 打开 CSVIDE 打开日志文件在回收站中File对象指向已删除路径路径含非法字符Windows 对CON,PRN,AUX等保留名敏感权限不足非管理员无法删除系统目录下文件。笔记给出健壮删除方案基于Files.deleteIfExists()import java.nio.file.*; Path path Paths.get(target/file.txt); try { Files.deleteIfExists(path); // ① 原子性删除失败抛具体异常 } catch (NoSuchFileException e) { // 文件不存在正常 } catch (DirectoryNotEmptyException e) { // 目录非空需先递归删除 Files.walk(path) .sorted(Comparator.reverseOrder()) .forEach(p - { try { Files.delete(p); } catch (IOException ex) { /* log */ } }); } catch (AccessDeniedException e) { // 权限不足尝试设置可写 try { Files.setAttribute(path, dos:readonly, false); Files.delete(path); } catch (IOException ex) { /* log */ } }FilesAPI 的优势在于异常类型明确NoSuchFileException,AccessDeniedException且walk()支持逆序遍历天然适合递归删除。7.2ObjectInputStream的反序列化安全为什么必须重写resolveClass()第 46 页“ObjectInputStream和ObjectOutputStream”中笔记用一个血泪经验开场“某次上线后服务 CPU 100%线程堆栈全是ObjectInputStream.readObject()排查发现是恶意客户端发送了超深嵌套的LinkedList触发readObject()无限递归”。根本原因是ObjectInputStream默认接受任意类包括Runtime、ProcessBuilder等危险类。笔记给出防御方案——继承ObjectInputStream并重写resolveClass()public class SafeObjectInputStream extends ObjectInputStream { private static final SetString ALLOWED_CLASSES Set.of( java.lang.String, java.util.ArrayList, com.example.User ); public SafeObjectInputStream(InputStream in) throws IOException { super(in); } Override protected Class? resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException { String className desc.getName(); if (!ALLOWED_CLASSES.contains(className)) { throw new InvalidClassException(Unauthorized class: className); } return super.resolveClass(desc); } }笔记强调白名单制比黑名单制可靠。ALLOWED_CLASSES应严格限定业务所需类且需定期审计。JDK 9 提供ObjectInputFilter但笔记认为白名单resolveClass()更直观可控。7.3Thread的七种状态与park()/unpark()wait()/notify()为何在LockSupport面前过时第 52 页“线程状态的转换”中笔记用状态流转图对比BLOCKED → (等待 monitor 锁) → RUNNABLE WAITING → (调用 wait()) → RUNNABLE (需 notify) TIMED_WAITING → (sleep(), wait(ms)) → RUNNABLE而LockSupport.park()的状态是WAITING但它不需要 synchronized 块也不依赖对象监视器// 传统 wait/notify必须 synchronized synchronized (lock) { lock.wait(); // 释放 lock进入 WAITING } // notify 必须在 synchronized(lock) 内调用 // LockSupport无锁 LockSupport.park(); // 当前线程 WAITING LockSupport.unpark(thread); // 唤醒指定线程无需锁笔记结论“LockSupport是AQSAbstractQueuedSynchronizer的基石ReentrantLock、Semaphore的底层都用它。wait/notify是面向对象监视器的遗留 APIpark/unpark是面向线程的现代原语。新代码请拥抱LockSupport”。从那以后我每次写涉及static块或finally的代码都会强制走一遍javap -c看字节码确认monitorenter/monitorexit的位置和return指令的顺序每次用反射第一反应不是setAccessible(true)而是问自己“有没有public接口能替代”每次设计序列化必画一张类图标出哪些字段要transient哪些类要进白名单。这份笔记的价值不在于它写了多少页而在于它让我养成了对每一个语法糖背后 JVM 行为的条件反射式质疑。希望帮到你。本文还有配套的精品资源点击获取