All posts by 龙生

Java术语

Java Development Kit(JDK)：编写Java程序的程序员使用的软件 Java Runtime Environment(JRE)：运行Java程序的用户使用的软件 Server JRE：在服务器上运行Java程序的软件 Standard Edition(SE)：用于桌面或简单服务器应用的Java平台 Enterprise Edition(EE)：用于复杂服务器应用的Java平台 Micro Edition(ME)：用于手机和其他小型设备的Java平台 Java FX：用于图形化用户界面的一个替代工具包，在Oracle的Java SE发布版本中提供 OpenJDK：Java SE的一个免费开源实现，不包含浏览器集成或JavaFX Java 2(J2)：一个过时的术语，用于描述1998 ~ 2006年之间的Java版本 Software Development Kit(SDK)：一个过时的术语，用于描述1998 ~ 2006年之间的JDK Update(u)：Oracle的术语，表示bug修正版本 NetBeans：Oracle的集成开发环境

搞钱

要用脑袋和胆子赚钱。

Java白皮書的關鍵術語

簡單性 面向對象 分佈式 健壯性 安全性 體系結構中立 可移植性 解釋型 高性能 多綫程 動態性

SpringBoot的AOP（@aspect注解）的简单使用

filter、interceptor、AOP的区别
filter作用于servlet
（通常指spring的）interceptor，拦截的对象是URL
AOP作用的对象可以是任何一个方法

SpringBoot中使用Aspect实现切面，超详细

Spring中的切面Aspect，这是Spring的一大优势。面向切面编程往往让我们的开发更加低耦合，也大大减少了代码量，同时呢让我们更专注于业务模块的开发，把那些与业务无关的东西提取出去，便于后期的维护和迭代。

Compilation error after upgrading to JDK 21 – “NoSuchFieldError: JCImport does not have member field

与JDK 21兼容的最小Lombok版本是1.18.30

单例模式的七种写法

什么意思呢？就是当前进程确保一个类全局只有一个实例。

那单例模式有什么好处呢？[1]

单例模式在内存中只有一个实例，减少了内存开支
单例模式只生成一个实例，所以减少了系统的性能开销
单例模式可以避免对资源的多重占用
单例模式可以在系统设置全局的访问点
那单例模式是银弹吗？它有没有什么缺点？

单例模式一般没有接口，扩展很困难
单例模式不利于测试
单例模式与单一职责原则有冲突
那什么情况下要用单例模式呢？

要求生成唯一序列号的环境
在整个项目中需要一个共享访问点或共享数据
创建一个对象需要消耗的资源过多
需要定义大量的静态常量和静态方法（如工具类）的环境

Java volatile关键字最全总结：原理剖析与实例讲解(简单易懂)

volatile是Java提供的一种轻量级的同步机制。Java 语言包含两种内在的同步机制：同步块（或方法）和 volatile 变量，相比于synchronized（synchronized通常称为重量级锁），volatile更轻量级，因为它不会引起线程上下文的切换和调度。但是volatile 变量的同步性较差（有时它更简单并且开销更低），而且其使用也更容易出错。

十分钟彻底掌握缓存击穿、缓存穿透、缓存雪崩

缓存击穿： 一个并发访问量比较大的key在某个时间过期，导致所有的请求直接打在DB上。
缓存穿透：缓存穿透指的查询缓存和数据库中都不存在的数据，这样每次请求直接打到数据库，就好像缓存不存在一样。
缓存雪崩： 当某⼀时刻发⽣⼤规模的缓存失效的情况，例如缓存服务宕机、大量key在同一时间过期，这样的后果就是⼤量的请求进来直接打到DB上，可能导致整个系统的崩溃，称为雪崩。

设计模式的6大原则

单一职责原则(Single Responsibility Principle, SRP) 一个类应该只有一个引起它变化的原因。 这意味着一个类应该只负责一项功能，而不是多种功能混杂在一起。 开闭原则(Open Closed Principle, OCP) 软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。 这意味着在不修改现有代码的情况下，可以添加新的功能，使系统具有良好的可扩展性。 里氏替换原则(Liskov Substitution Principle, LSP) 所有出现的地方，子类必须能够替换父类。 任何派生类对基类的替换都不能改变程序的行为，以确保程序的正确性。 接口隔离原则(Interface Segregation Principle, ISP) 客户端不应该被迫依赖它不使用的方法。 即不应该有一个大的接口，而是应该有许多小的接口，让客户端只依赖于它们真正需要的接口。 依赖倒置原则(Dependence Inversion Principle, DIP) 高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。 通过抽象和接口来降低模块间的耦合度。 迪米特法则(Law of Demeter, LoD) 又称“最少知道原则”。 一个对象应该对其他对象有尽可能少的了解，并且只与它的直接朋友进行交互，而不是与间接的朋友。