装饰模式

0x00 装饰模式

装饰模式（Decorator Pattern）是一种结构型设计模式，它允许在不改变现有类结构的前提下，动态地给对象添加新的功能。装饰模式通常用于替代继承，尤其是在需要扩展功能但又不想通过子类来实现的情况下。

在Java中，装饰模式的基本结构包括以下几个部分：

1. 抽象组件（Component）：定义了一个公共接口，所有具体组件和装饰器都必须实现该接口。
2. 具体组件（Concrete Component）：实现了抽象组件接口，并提供了基本的行为。
3. 装饰器（Decorator）：同样实现了抽象组件接口，它包含一个指向抽象组件类型的引用。装饰器通过其构造函数接收一个抽象组件对象，并通过组合而非继承的方式来扩展功能。
4. 具体装饰器（Concrete Decorator）：实现装饰器接口，并负责添加新行为或者修改现有行为。
   发布于: 2024/08/15

代理模式

0x00 代理模式

代理模式（Proxy Pattern）是一种结构型设计模式，它为其他对象提供一个代理以控制对这个对象的访问。代理模式的主要目的是在不直接暴露目标对象的情况下，通过代理对象来间接地操作目标对象。这样做的好处是可以增加额外的功能，比如权限检查、缓存、日志记录等，而不会修改原始对象的行为。

在 Java 中，代理模式可以通过多种方式实现，包括静态代理、动态代理（JDK 动态代理）和 CGLIB 动态代理。下面我们来分别介绍这些实现方式。

代理模式vs装饰器模式

about cap

线程锁

volatile 关键字

先说结论. volatile 降低了并发风险而非解决了风险. volatile 并不是万能的且用且珍惜.
volatile 只能保证读当前值的准确. 但毕竟任意操作一定是另一条指令.
使用了volatile只是会降低分析复杂代码的成本.尽量保护 volatile 变量的准确性.

0x00 Java 中 volatile 的原理

可见性：

• 当一个线程修改了一个 volatile 变量的值，其他线程能够立即看到这个变化。
• 这是因为 JVM 规范要求 volatile 变量的写操作会将新值直接写入主内存，并且通知其他线程该变量已被修改。
• 同样，volatile 变量的读操作会从主内存中读取该变量的最新值。

禁止指令重排序：

• 在编译器和处理器优化代码时，可能会对代码进行重排序以提高执行效率。
• 但是这种重排序可能会导致多线程程序中的错误行为。
• 使用 volatile 可以禁止某些类型的指令重排序，保证代码按照程序员预期的顺序执行。

不保证原子性：

• 尽管 volatile 提供了可见性和有序性，但它并不保证复合操作的原子性。
• 例如，即使使用 volatile 定义了一个整型变量，对该变量进行加减操作仍然可能不是原子性的。

多线程的创建

0x00 多线程的创建

有以下4种创建线程的方法

1. 继承Thread类

1
2
3
4
5

public class MyThread extends Thread {
    @Override
    public void run() {
    }
}

2. 实现Runnable接口

1
2
3
4
5

public class MyRunnable implements Runnable {
    @Override
    public void run() {
    }
}

抽象工厂模式

0x00 抽象工厂模式

抽象工厂模式（Abstract Factory Pattern）是一种创建型设计模式，它提供了一种接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类。与工厂模式不同的是，抽象工厂模式关注的是一个产品系列中的多个相关产品，并且这些产品通常需要一起工作。

工厂模式

单例模式

0x00 单例的几种实现方式:

• 饿汉式
• 懒汉式
• 静态内部类
• 枚举
• 双重校验锁

类图:

classDiagram

class Singleton{
    +private Singleton()
    +private static final Singleton instance
    +public static Singleton getInstance()
}

Singleton<|-- Singleton