Java-线程池

Java-线程池

如果我们要实现一个线程池，那至少应该先明白线程池的意义是什么：

线程池是一种线程管理机制，是为了复用已创建的线程，避免频繁的创建和销毁线程——这会消耗大量的CPU性能。

OK，这是我们目前的线程池，它几乎什么都没有：

1
2
3
4
5
6
public class MyThreadPool {

    public void execute(Runnable command){
      
    }
}

execute()接收一个任务Runnable command，command应该得到一个线程来执行。

1、我们先创建一个线程来把task跑起来吧：

1
2
3
4
public void execute(Runnable command){
  	Thread thread=new Thread(command);
  	thread.start();
}

这当然不符合线程池的意义——它每次对新加入的任务都是新创建了线程，任务完成后，线程就自动销毁，完全没有复用线程的过程。

2、如何让线程能够被复用呢？

1）首先，我们得让线程成为线程池的一部分，也就是新创建一个成员变量thread。

2）复用线程得让这个线程不会自动销毁，那我们就可以往这个线程里塞一个循环：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class MyThreadPool {
  
    Thread thread=new Thread(()->{
        while(true){
            /..../
        }
    });
  	
  	{
    	thread.start();
  	}

    public void execute(Runnable command){
        
    }
}

3）接下来就是把我们所有的任务放到这个线程中来执行了。

我们的方案是，在线程池中维护一个commandList来保存所有等待执行的任务，然后在thread不断地循环读取commandList，每执行完一个commamd就删除掉。

这样一来，所有新加入的任务，最终都会在thread中被执行。我们代码实现一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class MyThreadPool {

    List<Runnable> commandList=new ArrayList<>();
    Thread thread=new Thread(()->{
        while(true){
            if(!commandList.isEmpty()){
                Runnable command = commandList.remove(0);
                command.run();
            }
        }
    });
  	
  	{
    	thread.start();
  	}

    public void execute(Runnable command){
        commandList.add(command);
    }
}

3、OK，现在线程能够复用了，任务也能执行了，但是存在严重的性能浪费。

在上面的代码中，即使当前commandList为空，while 循环也依然不断地进行，严重浪费CPU性能，与线程池的意义相悖。

有没有一种代替commandList的数据结构，使得【当任务列表为空的时候，线程就会在这里阻塞，从而解放CPU；当任务列表不为空，又能停止阻塞呢，继续执行任务呢？】

有的xd，有的。我们先看是怎么做的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class MyThreadPool {

    BlockingQueue<Runnable> commandList=new ArrayBlockingQueue<>(1024);
    Thread thread=new Thread(()->{
        while(true){
            try {
                Runnable task = commandList.take();
                task.run();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }

        }
    });

    {
        thread.start();
    }

    public void execute(Runnable command){
        commandList.offer(command);
    }
}

BlockingQueue即阻塞队列，take()会在队列中没有元素时自动阻塞，当加入元素后解除阻塞，执行任务。注意在创建BlockingQueue要指定最大容量，防止无限制的添加任务。

4、OK，现在线程能够实现复用。但是我们目前只有一个线程，自然是不够用的。

创建ThreadList来维护所有已存在的线程，并且设置一个threadSize来规定线程池的大小，具体的逻辑是：

  1. 如果当前线程池的线程数量小于threadSize，那么就新建线程。

  2. 把任务加入阻塞队列。

  3. 每个线程都应该执行这段代码

    1
    2
    3
    4
    5
    6
    7
    8
    while(true){
      try {
        Runnable command = commandList.take();
        command.run();
      } catch (InterruptedException e) {
        e.printStackTrace();
      }
    }

完整实现一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class MyThreadPool {

    BlockingQueue<Runnable> commandList=new ArrayBlockingQueue<>(1024);

    Runnable task=()->{
        while(true){
            try {
                Runnable command = commandList.take();
                command.run();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    };

    int threadListSize=10;
    List<Thread> threadList=new ArrayList<>();

    public void execute(Runnable command) {
        if(threadList.size()<threadListSize){
            Thread thread = new Thread(task);
            thread.start();
        }
      	commandList.offer(command);
    }
}

5、如果threadSize规定的线程数量不够用了，那该怎么办？

核心线程忙不过来，导致任务堆积在阻塞队列中，直到阻塞队列被塞满，此时commandList.offer(command)就会执行失败，任务不会被执行。

此时我们应该允许再额外创建线程，来分摊核心线程的压力。

我们把原先创建的threadList改名为coreList，表示这是【核心线程】，最大数量为coreThreadSize；而再额外创建的线程，专门用一个supportList来维护，表示这是【辅助线程】。【核心线程】数量 + 【辅助线程】数量不应该超过maxSize。

OK，我们重新梳理一下execute(Runnable command)流程：

  1. 如果当前核心线程数量未满，则创建线程，把任务加入阻塞队列后即可返回。
  2. 如果核心线程数量已满，但是commandList.offer(command)返回 true ，表示核心线程还可以忙的过来，那也可以直接返回。
  3. 如果commandList.offer(command)返回 false，表示阻塞队列已经被塞满了，那此时就应该创建辅助线程（需满足总线程数不超过maxSize），来帮忙清理阻塞队列。
  4. 创建完辅助线程并start()后，再尝试commandList.offer(command)，如果还失败，那说明任务实在是太多了，确实不能再添加任务了，此时应该抛一个异常，表示【并发任务数量已达上限】。

代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
public class MyThreadPool {

    BlockingQueue<Runnable> commandList=new ArrayBlockingQueue<>(1024);
    int coreThreadSize =10;
    int maxSize=20;
    List<Thread> coreList =new ArrayList<>();
    List<Thread> supportList=new ArrayList<>();

    Runnable task=()->{
        while(true){
            try {
                Runnable command = commandList.take();
                command.run();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    };

    public void execute(Runnable command) {
        if(coreList.size()< coreThreadSize){
            Thread thread = new Thread(task);
            coreList.add(thread);
            thread.start();
        }
        if(commandList.offer(command)){
            return;
        }
        if(coreList.size()+supportList.size()<maxSize){
            Thread thread = new Thread(task);
            supportList.add(thread);
            thread.start();
        }
        if(!commandList.offer(command)){
            throw new RuntimeException("阻塞队列已满");
        }

    }
    
}

6、现在的版本，线程一旦被创建，就会一直存在，即使阻塞队列中已经长时间没有新任务。

这对资源管理是不利的。

  • 对于核心线程，我们可以接受他们一直在工作；

  • 对于辅助线程，如果长时间不被使用的情况下，应该自动结束辅助线程的生命周期。

重点在 take() 这个函数，因为他会一直阻塞在这里。如果take()能接收一个超时时间，问题就好解决了。

BlockingQueue 中还有一个 API 满足这个要求：

1
E poll(long timeout, TimeUnit unit)

他的功能与take()一致，但是能接收timeout参数，如果规定时间内没有拿到元素，则直接返回null。

这就很简单了，直接改代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
public class MyThreadPool {

    /.../
    int timeout=1;
  	TimeUnit timeUnit=TimeUnit.MINUTES;

    Runnable coreTask =()->{
        while(true){
            try {
                Runnable command = commandList.take();
                command.run();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    };
    Runnable supportTask =()->{
        while(true){
            try {
                Runnable command = commandList.poll(timeout, timeUnit);
                if(command==null){
                    break;
                }
                command.run();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    };

    public void execute(Runnable command) {
        if(coreList.size()< coreThreadSize){
            Thread thread = new Thread(coreTask);
            coreList.add(thread);
            thread.start();
        }
        if(commandList.offer(command)){
            return;
        }
        if(coreList.size()+supportList.size()<maxSize){
            Thread thread = new Thread(supportTask);
            supportList.add(thread);
            thread.start();
        }
        if(!commandList.offer(command)){
            throw new RuntimeException("阻塞队列已满");
        }

    }

}

7、现在我们的线程池的功能已经基本完善——唯一缺乏的在于，我们对于阻塞队列爆满的情况，还没有做出一个合适的处理，只是抛出了一个异常。

我们可以处理的方式可以有很多种：记录日志、保存在数据库中、或者发送一个消息等等。

我们把这种处理方式抽象出来，称为【拒绝策略】。可以传入被拒绝执行的任务command以及线程池实例，方便支持更多的拒绝策略。

1
2
3
4
5
6
7
/**
 * 拒绝策略
 * @author Michael
 */
public interface RejectHandle {
    void reject(Runnable command,MyThreadPool myThreadPool);
}

定义成接口，开发者就可以实现这个接口，自定义异常处理策略。

8、OK，最后，优化一下我们的代码：

1）提供一个构造函数，构造参数包括：

1
2
3
4
5
6
int coreThreadSize =10;
int maxSize=20;
int timeout=1;
TimeUnit timeUnit=TimeUnit.MINUTES;
BlockingQueue<Runnable> commandList=new ArrayBlockingQueue<>(1024);
RejectHandle rejectHandle;

2）创建CoreThread和SupportThread，继承Thread，实现run()方法，将coreTask和supportTask都放到各自的run()方法中去。

9、最终版本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
package myThreadPool;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.TimeUnit;

/**
 * @author Michael
 */
public class MyThreadPool {

    private int coreThreadSize =10;
    private int maxSize=20;
    private int timeout=1;
    private TimeUnit timeUnit=TimeUnit.MINUTES;
    private BlockingQueue<Runnable> commandList=new ArrayBlockingQueue<>(1024);
    private RejectHandle rejectHandle;
    private List<Thread> coreList =new ArrayList<>();
    private List<Thread> supportList=new ArrayList<>();


    public MyThreadPool(int coreThreadSize, int maxSize, int timeout, TimeUnit timeUnit, BlockingQueue<Runnable> commandList, RejectHandle rejectHandle) {
        this.coreThreadSize = coreThreadSize;
        this.maxSize = maxSize;
        this.timeout = timeout;
        this.timeUnit = timeUnit;
        this.commandList = commandList;
        this.rejectHandle = rejectHandle;
    }


    public void execute(Runnable command) {
        if(coreList.size()< coreThreadSize){
            Thread thread = new CoreThread();
            coreList.add(thread);
            thread.start();
        }
        if(commandList.offer(command)){
            return;
        }
        if(coreList.size()+supportList.size()<maxSize){
            Thread thread = new SupportThread();
            supportList.add(thread);
            thread.start();
        }
        if(!commandList.offer(command)){
            rejectHandle.reject(command,this);
        }

    }
    class CoreThread extends Thread{
        @Override
        public void run(){
            while(true){
                try {
                    Runnable command = commandList.take();
                    command.run();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }

    class SupportThread extends Thread{
        @Override
        public void run(){
            while(true){
                try {
                    Runnable command = commandList.poll(timeout, timeUnit);
                    if(command==null){
                        break;
                    }
                    command.run();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }
}


/**
 * 拒绝策略
 * @author Michael
 */
public interface RejectHandle {
    void reject(Runnable command,MyThreadPool myThreadPool);
}

特别提醒，这只是一个demo，真正的线程池操作是要保证线程安全，显然在本文中并没有实现这一点；在源码中，是使用了ReentrantLock来进行并发控制。

展开全文 >>

Java-手写HashMap

[TOC]

Java-手写HashMap

1
2
3
public class MyHashMap{
  
}

我将顺着下面的这些问题，一步步完成MyHashMap的实现。（没有实现红黑树）

一、HashMap 为什么选择数组+链表作为底层数据结构？

  • 数组的查询复杂度是 O(1)，但插入效率（尤其是中间和头部插入）较低。
  • 链表的查询复杂度是 O(n)，但插入复杂度为 O(1)。
  • 结合数组和链表的优点，提高了查询和插入效率。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
package myHashMap;


import java.util.HashMap;
import java.util.Objects;

/**
 * @author Michael
 */
public class MyHashMap<K,V> {

    Node<K,V>[] table;
  
    class Node<K,V>{
        K key;
        V value;
        Node<K,V> next;

        public Node(K key,V value,Node<K,V> next){
            this.key=key;
            this.value=value;
            this.next=next;
        }
    }

}

二、数组的大小怎么规定？

源码中规定，数组的大小必须等于2^n，这是因为：

  1. 如果 table 的长度是 2^n，元素在数组中的索引计算 index = hash % table.length 可等效为 index = hash & (table.length - 1)，用位运算替代取模运算，提高计算效率。

  2. 当数组扩容时，如果元素原本分布均匀，扩容后也能保持均匀分布。例如：

    • 假设某元素的哈希值为 10101100

    • 旧数组计算索引：

      1
      2
      3
      makefile复制编辑hash        = 10101100  
      length - 1  = 00000111  
      index       = 00000100  (4)

    • 新数组计算索引：

      1
      2
      3
      makefile复制编辑hash        = 10101100  
      length - 1  = 00001111  
      index       = 00001100  (12)

    • 观察第四位（从右数）：

      • 高位为 0：位置不变。
      • 高位为 1：移动到新位置（原索引位置 + 原容量）。

源码中，初始化的数组大小为16。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
package myHashMap;


import java.util.HashMap;
import java.util.Objects;

/**
 * @author Michael
 */
public class MyHashMap<K,V> {

    Node<K,V>[] table;
    int DEFAULT_INITIAL_CAPACITY=1<<4;

    public MyHashMap(){
        table=new Node[DEFAULT_INITIAL_CAPACITY];
    }

  
    class Node<K,V>{
        K key;
        V value;
        Node<K,V> next;

        public Node(K key,V value,Node<K,V> next){
            this.key=key;
            this.value=value;
            this.next=next;
        }
    }

}

三、数组什么时候进行扩容？

我们定义一个size来存储【数组当前实际存储的元素个数】，然后有两个问题：

1）什么时候进行扩容？

2）扩容扩到多少？

对于问题一，HashMap的源码中，是当size=table.length*0.75时，就进行扩容。

  • 我们将0.75称为负载因子，定义LOAD_FACTOR；
  • table.length*LOAD_FACTOR就称为阈值，定义threshold。

对于问题二，HashMap的源码中是将数组大小翻倍，这样保证扩容后的数组长度依然是2^n。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
package myHashMap;


import java.util.HashMap;
import java.util.Objects;

/**
 * @author Michael
 */
public class MyHashMap<K,V> {

    Node<K,V>[] table;
    int DEFAULT_INITIAL_CAPACITY=1<<4;
    float LOAD_FACTOR=0.75f;
    int size=0;
    int threshold=(int)(DEFAULT_INITIAL_CAPACITY*LOAD_FACTOR);

    public MyHashMap(){
        table=new Node[DEFAULT_INITIAL_CAPACITY];
    }


    public int getThreshold(){
        return table==null?0:(int)(table.length*LOAD_FACTOR);
    }

    class Node<K,V>{
        K key;
        V value;
        Node<K,V> next;

        public Node(K key,V value,Node<K,V> next){
            this.key=key;
            this.value=value;
            this.next=next;
        }
    }

}

四、元素的 hash 值是直接返回 hashCode() 吗？

  • 若 hash = obj.hashCode()，索引计算 index = hash & (length - 1) 仅受 hashCode() 低位影响，高位不起作用，容易导致冲突。

  • 为了让高位也参与计算，我们这样计算 hash 值：

    1
    2
    hash = (hashCode) ^ (hashCode >>> 16)
    index = hash & (length - 1)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
package myHashMap;


import java.util.HashMap;
import java.util.Objects;

/**
 * @author Michael
 */
public class MyHashMap<K,V> {

    Node<K,V>[] table;
    int DEFAULT_INITIAL_CAPACITY=1<<4;
    float LOAD_FACTOR=0.75f;
    int size=0;
    int threshold=(int)(DEFAULT_INITIAL_CAPACITY*LOAD_FACTOR);

    public MyHashMap(){
        table=new Node[DEFAULT_INITIAL_CAPACITY];
    }

    public int hash(Object key){
        int h;
        return key==null?0:(h=key.hashCode())^(h>>>16);
    }

    public int getIndex(int hash){
        return hash&(table.length-1);
    }

    public int getThreshold(){
        return table==null?0:(int)(table.length*LOAD_FACTOR);
    }

    class Node<K,V>{
        K key;
        V value;
        Node<K,V> next;

        public Node(K key,V value,Node<K,V> next){
            this.key=key;
            this.value=value;
            this.next=next;
        }
    }

}

五、HashMap 的 put()、get()、resize() 方法

put()方法：

  1. table 是否已初始化，若未初始化则先进行初始化。
  2. 是否超过阈值，若超出则先扩容resize()。
  3. 计算在数组中的索引值。
  4. 若索引位置为空，直接插入。
  5. 若索引位置不为空，则遍历链表：
    • 若 key 相同，直接覆盖。这里 key 相同指的是：内存地址相同；或者，如果内存地址不同，那么通过equals()判断值是否相同；
    • 若 key 不同且已遍历到链表尾部，则新增节点插入链表尾部。

get()与resize()方法流程不再叙述，resize()就是按创建一个更长（翻倍）的数组，然后进行复制。

直接看代码吧！

六、最终版本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
package myHashMap;


import java.util.HashMap;
import java.util.Objects;

/**
 * @author Michael
 */
public class MyHashMap<K,V> {

    Node<K,V>[] table;
    int DEFAULT_INITIAL_CAPACITY=1<<4;
    float LOAD_FACTOR=0.75f;
    int size=0;
    int threshold=(int)(DEFAULT_INITIAL_CAPACITY*LOAD_FACTOR);

    public MyHashMap(){
        table=new Node[DEFAULT_INITIAL_CAPACITY];
    }

    public int hash(Object key){
        int h;
        return key==null?0:(h=key.hashCode())^(h>>>16);
    }

    public int getIndex(int hash){
        return hash&(table.length-1);
    }

    public void put(K key,V value){
        //1. table是否已初始化，如果没有，则要先初始化table
        if(table==null){
            table=new Node[DEFAULT_INITIAL_CAPACITY];
        }
        //2. 是否会超过阈值，如果是，则要先扩容
        if(size+1>getThreshold()){
            resize();
        }
        //3. 计算得到在数组中的索引值
        int index=getIndex(hash(key));
        //4. 索引处如果为空，则直接插入
        Node<K, V> node = table[index];
        if(node==null){
            node=new Node<>(key,value,null);
            size+=1;
        }
        //5. 索引处如果不为空，则从第一个链表节点开始遍历：
        // 5.1 如果有key值相同，则直接返回。这里 key 相同指的是：内存地址相同；或者，如果内存地址不同，那么通过`equals()`判断值是否相同；
        // 5.2 如果没有key值相同，则此时已经在链表尾部，那就新创建节点，并插入到索引处链表的尾部
        else{
            Node<K,V> prev=node;
            while(node!=null){
                if(Objects.equals(node.key, key)){
                    return;
                }
                prev=node;
                node=node.next;
            }
            Node newNode = new Node(key, value, null);
            prev.next=newNode;
            size+=1;
        }
    }

    public V get(K key){
        if(table==null||table.length<1){
            return null;
        }
        int index=getIndex(hash(key));
        Node<K, V> node = table[index];
        if(node==null){
            return null;
        }else{
            while(node!=null){
                if(node.key==key||Objects.equals(node.key,key)){
                    return node.value;
                }
                node=node.next;
            }
        }
        return null;
    }

    public void resize(){
        if(table==null){
            table=new Node[DEFAULT_INITIAL_CAPACITY];
            return;
        }
        Node<K,V>[] oldTab=table;
        int newCapacity=oldTab.length<<2;
        Node<K,V>[] newTab=new Node[newCapacity];
        table=newTab;
        for(int i=0;i< oldTab.length;i++){
            Node<K, V> node = oldTab[i];
            while(node!=null){
                put(node.key,node.value);
                node=node.next;
            }
        }
    }

    public int getThreshold(){
        return table==null?0:(int)(table.length*LOAD_FACTOR);
    }

    class Node<K,V>{
        K key;
        V value;
        Node<K,V> next;

        public Node(K key,V value,Node<K,V> next){
            this.key=key;
            this.value=value;
            this.next=next;
        }
    }

}

六、为什么 Java 8 更新，链表长度达到 8 时转换为红黑树？

当链表过长时，由于链表的查询复杂度是O(n)，会导致查询效率降低；所以用时间复杂度为O(log n)的红黑树进行优化。

但事实上，根据泊松分布公式，出现8个 hash 冲突的几率非常低；所以一旦出现8个以上 hash 冲突，多半是误操作或者漏洞攻击。

之前就有利用 HashMap 这种链表结构攻击，导致服务器崩溃，所以这个变红黑树其实是补漏洞。正常操作很难出现红黑树。

展开全文 >>

Java-并发与锁

[TOC]

Java-锁与并发

一切还要从一个场景出发：

ArrayList是一个线程不安全的集合，请封装它的增删改查方法，实现线程安全。

一、开始

这很简单，我们有两个实现思路：synchronized或者lock。不多解释，直接看代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
package safeList;

import java.util.ArrayList;
import java.util.List;

/**
 * @author Michael
 */
public class SynchronizedSafeList {
    private List<Object> list=new ArrayList<>();

    public synchronized void add(Object obj) {
        list.add(obj);
    }

    public synchronized void remove(int index) {
        list.remove(index);
    }

    public synchronized void update(int index,Object obj) {
        list.set(index,obj);
    }

    public synchronized Object get(int index) {
        return list.get(index);
    }
}


package safeList;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.locks.ReentrantLock;

/**
 * @author Michael
 */
public class ReentrantLockSafeList {

    private List<Object> list=new ArrayList<>();
    private final ReentrantLock lock=new ReentrantLock();

    public void add(Object obj){
        lock.lock();
        try{
            list.add(obj);
        }finally {
            lock.unlock();
        }
    }

    public void remove(int index){
        lock.lock();
        try{
            list.remove(index);
        }finally {
            lock.unlock();
        }
    }

    public void update(int index,Object obj){
        lock.lock();
        try{
            list.set(index,obj);
        }finally {
            lock.unlock();
        }
    }

    public Object get(int index){
        lock.lock();
        try{
            return list.get(index);
        }finally {
            lock.unlock();
        }
    }
}

不管是用synchronized还是lock，都是给四个方法简单粗暴的上了锁，这样能够实现写写互斥、读写互斥、读读互斥——唉，这不对吧，读读是不应该互斥的。

lock还有另一个实现类：ReentrantReadWriteLock，可以帮助我们实现读写锁分离，读读之间不互斥，直接看代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
package safeList;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.locks.ReentrantLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;

/**
 * @author Michael
 */
public class ReentrantReadWriteLockSafeList {
    private List<Object> list=new ArrayList<>();
    private final ReentrantReadWriteLock lock=new ReentrantReadWriteLock();

    public void add(Object obj){
        lock.writeLock().lock();
        try{
            list.add(obj);
        }finally {
            lock.writeLock().unlock();
        }
    }

    public void remove(int index){
        lock.writeLock().lock();
        try{
            list.remove(index);
        }finally {
            lock.writeLock().unlock();
        }
    }

    public void update(int index,Object obj){
        lock.writeLock().lock();
        try{
            list.set(index,obj);
        }finally {
            lock.writeLock().unlock();
        }
    }

    public Object get(int index){
        lock.readLock().lock();
        try{
            return list.get(index);
        }finally {
            lock.readLock().unlock();
        }
    }
}

这样，我们就完成了对一个ArrayList的增删改查封装，保证了线程安全。

这是我在面试时被问的一道题目，其实我对上面的做法还是很在意：直接使用ReentrantReadWriteLock似乎有点过于轮椅了，只要知道这个类，就可以轻松的实现要求。

那么能不能给自己上点难度，提高一点程序设计理解呢？OK，于是一个机灵，我决定自己实现一个简单的MyReadWriteLock，不求细节，思路为主。

二、MyReadWriteLock

1、联想到信号量

我想到了一个很类似的场景：操作系统进程与线程的【读者-写者】问题：有读者和写者两组并发进程，共享一个文件，要求：

  • 允许多个读者可以同时对文件执行读操作
  • 只允许一个写者往文件中写信息
  • 任何一个写者在完成写操作之前不逊于其他读者或写者工作。

要求2、3很好实现，只要为文件设一个信号量rw，然后用P、V操作同步即可。稍难一点的地方在于：怎么保证读读之间不互斥？

我们的做法是：设置一个变量readCount表示当前读进程的数量。当每次读进程要对信号量rw进行P操作时，先检查readCount是否等于0，如果等于，说明这是第一个读进程，那么执行P(rw)；如果不等于0，说明已经有读进程在占用文件了，其他读进程可以直接读，但是不用P(rw)，只需要把readCount++就可以了。

我们就参考这种思路来实现一下。

2、实现

下面的方法：

  • 用synchronized关键字来保证原子性。
  • 用wait()和notifuAll()实现等待和唤醒线程。
  • 附上一提，我们不需要用volatile保证变量的可见性，因为synchronized也包括了保证可见性。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class MyReadWriteLock{
  private int readCount=0;
  private boolean writeFlag=false;
  
  public synchronized void readLock(){
    while(writeFlag){
      wait();
    }
    readCount++;
  }
  
  public synchronized void writeLock(){
    while(writeFlag||readCount>0){
      wait();
    }
    writeFlag=true;
  }
  
  public synchronized void readUnlock(){
    readCount--;
    if(readCount==0){
      notifyAll();
    }
  }
  
  public synchronized void writeUnlock(){
    writeFlag=false;
    notifyAll();
  }
}

OK，这样我就根据自己的理解，设计了一个MyReadWriteLock的实现方案——然而，这其实是一坨。

  • 看看我是使用什么保证操作之间的原子性的？

    synchronized——它是Java底层实现的锁机制，特点是重量级，随意使用synchronized会导致并发性能严重降低；相对来说，lock的机制就要稍轻量一些。

  • 我有保证线程上的锁只能被自己释放吗？

    没有，如果有两个线程用我这套锁去同步，那一个线程完全可以不讲武德：不进行writeLock()或者readLock()，直接先writeUnlock()或者readUnlock()，把别人的锁释放了，自己再锁上；另一个线程也可以如此。那所谓的锁机制不就成了君子协定了吗？

  • 进程间是怎么样通信的？

    使用的是 Java 自带的wait()和notifyAll()，这还是要建立在使用synchronized的基础上——这些方法只能在 synchronized 代码块或 synchronized 方法中使用，否则会抛出 IllegalMonitorStateException。

    而且，notifyAll()是唤醒所有线程，那么这些线程又要全部起来竞争一下这把锁，又消耗了一波CPU资源。

所以我又想：那lock的底层实现是什么？能不能借鉴学习一下？

三、Lock的底层实现原理

Java 主要提供了两种方式来实现锁：

  • synchronized 关键字（JVM 层面）
  • Lock 接口（ReentrantLock 等）

这两种方式的底层实现都依赖于 CAS、自旋、锁升级机制等技术。

1、CAS（Compare And Swap）

CAS 是 无锁编程（Lock-Free）中常用的原子操作，它通过硬件指令来保证 某个变量的更新是线程安全的，避免使用互斥锁（synchronized），提高性能。如果你知道数据库中的【乐观锁】，那下面的原理一定非常好理解。

核心原理：

1）CAS需要三个值

  • V：当前内存中的实际值
  • E：旧值
  • N：新值

2）只有当V=E时，才会将V更新为N；否则说明已经有其他线程修改了V，本次操作失败。

也就是说，CAS操作其实就是根据【乐观锁思想】保证了下面操作的原子性：

1
2
3
if(V==E){
	 V=N;
}

3）示例：

1
2
3
4
AtomicINteger atomicInt = new AtomicInteger(0);
// 先比较，只要当【当前值】等于【旧值】0时，才会更新为【新值】10
// CAS 操作是原子性的
atominInt.compareAndSet(0,10)

2、自旋锁（Spin Lock）

自旋锁是一种非阻塞锁概念，当线程想要占用锁时：

  • 如果锁被占用，线程不会进入阻塞，而是循环检查锁是否被释放，这种忙等待的方式称为自旋。

3、Lock溯源

Lock的实现过程有这么几个关键词：

  • int 类型状态
  • 双向链表
  • CAS+自旋。

在lock的构造函数中，定义了一个NonFairSync，

1
2
3
public ReentrantLock() {
  sync = new NonfairSync();
}

NonfairSync 又是继承于Sync

1
static final class NonfairSync extends Sync

一步一步往上找，找到了AbstractQueuedSynchronizer

1
abstract static class Sync extends AbstractQueuedSynchronizer

最后这个鬼，又是继承于AbstractOwnableSynchronizer(AOS)。

他们之间的关系如图：

image-20250313012231332

  • AOS主要是保存获取当前锁的线程对象。
  • FairSync 与 NonfairSync的区别在于，是不是保证获取锁的公平性，因为默认是NonfairSync。
  • AQS中包含了主要的代码。

4、手写MyLock

这是我们的测试main函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class LockExample {
    public static void main(String[] args) throws InterruptedException {
        int[] count = {100};
        MyLock myLock=new MyLock();


        Thread[] threads=new Thread[10];
        for (int i = 0; i < 10; i++) {
            Thread thread = new Thread(new Runnable() {
                @Override
                public void run() {
                    myLock.lock();
                    count[0]--;
                    myLock.unlock();
                }
            });
            threads[i]=thread;
        }

        for (int i = 0; i < 10; i++) {
            threads[i].start();
        }

        for (int i = 0; i < 10; i++) {
            threads[i].join();
        }

        System.out.println(count[0]);
    }
}

这是目前的锁：

1
2
3
4
5
6
7
8
9
public class MyLock {
    public void lock() {
      
    }

    public volid unlock() {
      
    }
}

我们顺着思路，一步一步填充MyLock。

1、多线程同步的基础是锁，那么锁到底做了什么呢？

先lock()，这里lock是需要阻塞的，如果没有阻塞则成功返回，表示拿到了锁。

那么我们写一个循环，并且调用一个原子操作 CAS，如果原子操作成功了，就返回；如果失败了，就一直循环，相当于阻塞。

那释放锁自然是把flag置回 false。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class MyLock {
    private final AtomicBoolean flag = new AtomicBoolean(false);

    public void lock() {
        while (true) {
            if (flag.compareAndSet(false, true)) {
                return;
            }
        }
    }

    public void unlock() {
        flag.compareAndSet(true, false);
    }
}

2、如果能完成第一步，那么我们 LockExample 中的多线程执行就能够得到正确的结果，说明我们已经实现了一个简易锁。

看看我们还有没有其他的问题？有的。

我们的锁现在还不能辨识是哪个线程抢到了自己，换句话说，一个线程可以释放已经被其他线程占用的锁——只要它不守规矩，不先lock()，直接unlock()，就可以了。

我们需要做到： lock 只能被当前占用的线程释放。

实现：

  • 给 MyLock 新增一个成员变量owner。
  • 当线程抢到锁时，把owner设置当前线程。
  • 当释放锁时，判断当前线程是否为owner，不是的话，就抛个异常出来。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
private Thread owner = null;

public void lock() {
  while (true) {
    if (flag.compareAndSet(false, true)) {
      owner = Thread.currentThread();
      return;
    }
  }
}

public void unlock() {
  if (owner != Thread.currentThread()) {
    throw new RuntimeException("当前线程并不占用锁，不允许释放锁");
  }
  flag.compareAndSet(true, false);
}

3、现在有点像样了，但是还不行。目前，所有线程在没拿到锁后，都会不断循环尝试获取锁，这是一种对CPU的不必要消耗。

我们可以设计：当线程没拿到锁时，进行阻塞：LockSupport.park()；直到被别人唤醒，才继续争抢锁。

这个唤醒的工作自然是由释放锁的线程来完成了，但是这又紧接着许多问题：

  • 问题一：我们上哪去找正在等待的线程？
  • 问题二：如果有多个正在等待的线程，应该唤醒哪一个呢？

带着这两个问题，我们需要维护一个【等待链表】（为了方便查询，设计成双向），这个链表的节点结构是这样的：

1
2
3
4
5
6
7
8
9
class Node{
  Node prev;
  Node next;
  Thread current;

  Node(Thread thread){
    this.current=thread;
  }
}

在 MyLock 中维护这个链表的【头结点】 Node head 以及【尾节点】Node tail。而唤醒线程的原则，我们就遵守【先进先出】。

这样我们就可以回答上面的两个问题了：

  • 问题一解：用一个双向链表维护被阻塞的线程。
  • 问题二解：遵守【先进先出】原则。

这里还有一个重点：

head和tail是所有线程都能访问的，意味着也面临多线程操作，举个例子：

1
2
3
current.prev=tail;
tail.next=current;
tail=current;

这段代码在多线程情况下是肯定会出问题的。

所以当我们对head、tail进行各种引用操作时，也要保证原子性——用【原子引用】包装head、tail：

1
2
private AtomicReference<Node> head=new AtomicReference<>(new Node());
private AtomicReference<Node> tail=new AtomicReference<>(head.get());

OK，继续改造！

每次阻塞一个线程时，我们设计以下思路：

  1. 先创建一个节点node，插入到链表，并维护双向链表结构。
  2. 让线程休眠：LockSupport.park()
  3. 当被唤醒时，要进行判断：是不是轮到自己了？以及是不是真能抢到锁？如果均为肯定，则加锁；如果不是，则继续休眠，等待被唤醒。

这里的第1点是有问题的：可能有多个线程并发的要插入到这个等待队列中，这也是我们使用原子引用封装head、tail的原因

所以第1点应该改为：先创建一个节点node，循环的尝试插入到链表，直到成功，并维护双向链表结构。

4、OK，整理一下上述思路，我们就可以得到一个实现了 lock() 的 MyLock，让我们直接用代码概括吧。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
public class MyLock {
    private final AtomicBoolean flag = new AtomicBoolean(false);
    private Thread owner = null;
    private AtomicReference<Node> head = new AtomicReference<>(new Node());
    private AtomicReference<Node> tail = new AtomicReference<>(head.get());

    public void lock() {
        // 拿到锁直接返回
        if (flag.compareAndSet(false, true)) {
            owner = Thread.currentThread();
            return;
        }
        // 没拿到锁的话，则要安全的把自己放在链表上
        Node current = new Node();
        current.thread = Thread.currentThread();
        while (true) {
            Node currentTail = tail.get();
            if (tail.compareAndSet(currentTail, current)) {
                current.prev = currentTail;
                currentTail.next = current;
                break;
            }
        }
        // 拿到锁的话，要安全的把自己从链表中删除
        while (true) {
            // 休眠
            LockSupport.park();
            if (head.get().next == current && flag.compareAndSet(false, true)) {
                owner = Thread.currentThread();
                head.set(current);
                current.prev.next = null;
                current.prev = null;
                return;
            }
        }

    }

    public void unlock() {
        if (owner != Thread.currentThread()) {
          	throw new IllegalStateException("当前线程并不占用锁，不允许释放锁");
        }
        flag.compareAndSet(true, false);
    }

    class Node {
        Node prev;
        Node next;
        Thread thread;
    }

}

5、我们现在开始补充释放锁 unlock() 的逻辑。

1
2
3
4
5
6
public void unlock() {
  	if (owner == Thread.currentThread()) {
    	flag.compareAndSet(true, false);
  	}
  	throw new IllegalStateException("当前线程并不占用锁，不允许释放锁");
}

我们在lock()中已经实现了：

  • 线程如果拿到锁，则直接返回
  • 如果没拿到锁的话，则要安全的把自己放在链表上，然后休眠。
  • 被唤醒后，如果能拿到锁的话，要安全的把自己从链表中删除。

而在unlock()中，我们其实就只要实现【当一个线程释放锁时，唤醒等待队列中的第一个线程】。

直接上代码：

1
2
3
4
5
6
7
8
9
10
public void unlock() {
  	if (owner != Thread.currentThread()) {
    		throw new IllegalStateException("当前线程并不占用锁，不允许释放锁");
  	}
  	Node headNode = head.get();
  	flag.set(false);
  	if(headNode.next!=null){
    		LockSupport.unpark(headNode.next.thread);
  	}
}

这里的flag.set(flag)不需要使用CAS操作，因为我们分析可知，此处是不可能有竞争的。

这里有两点非常重要：

  • flag.set(false)一定要在 LockSupport.unpark(headNode.next.thread);之前，因为你要唤醒别的线程去抢锁，你肯定得先把锁释放了。

  • flag.set(false)一定要在Node headNode = head.get();之后，因为一旦flag.set(false)，那就意味着所有的线程都可以并发，执行下面的代码；

    如果代码写成这样：

    1
    2
    3
    4
    5
    flag.set(false);
    Node headNode=head.get();  //(1)
    if(headNode.next!=null){
        LockSupport.unpark(headNode.next.thread);   //(2)
    }

    这里（2）处的headNode与（1）处的headNode就可能指向的不是同一个对象了。

6、OK，整理一下我们当前的版本。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
public class MyLock {
    private final AtomicBoolean flag = new AtomicBoolean(false);
    private Thread owner = null;
    private AtomicReference<Node> head = new AtomicReference<>(new Node());
    private AtomicReference<Node> tail = new AtomicReference<>(head.get());

    public void lock() {
        // 拿到锁直接返回
        if (flag.compareAndSet(false, true)) {
            owner = Thread.currentThread();
            return;
        }
        // 没拿到锁的话，则要安全的把自己放在链表上
        Node current = new Node();
        current.thread = Thread.currentThread();
        while (true) {
            Node currentTail = tail.get();
            if (tail.compareAndSet(currentTail, current)) {
                current.prev = currentTail;
                currentTail.next = current;
                break;
            }
        }
        // 拿到锁的话，要安全的把自己从链表中删除
        while (true) {
            // 休眠
            LockSupport.park();
            if (head.get().next == current && flag.compareAndSet(false, true)) {
                owner = Thread.currentThread();
                head.set(current);
                current.prev.next = null;
                current.prev = null;
                return;
            }
        }

    }

    public void unlock() {
        if (owner != Thread.currentThread()) {
            throw new IllegalStateException("当前线程并不占用锁，不允许释放锁");
        }
        Node headNode = head.get();
        flag.set(false);
        if(headNode.next!=null){
            LockSupport.unpark(headNode.next.thread);
        }
    }

    class Node {
        Node prev;
        Node next;
        Thread thread;
    }

}

我在这里还应该提醒一点：

我们这里实现的并不是一个严格保证【先到先得】机制的锁。我们能保证的是：如果一个进程进入阻塞队列了，那么在这个阻塞队列的范围内，我们保证【先到先得】。

如何理解？假设这样一个场景：

当线程A执行完unlock()中的 LockSupport.unpark(headNode.next.thread);这一条语句，此时锁被释放，等待队列中的线程B被唤醒；

同时新来了一个线程C，因为锁被释放了，所以它直接快B一步，抢到了锁；

线程B发现还是抢不到锁，所以再次休眠，等待线程C的唤醒；

也许被线程C唤醒时，又会跑来一个线程D，重复发生上述故事………

这在我们的代码中是完全可能发生的。事实上，这就是所谓的【非公平锁】。

7、如何实现一个公平锁呢？

其实很简单，引起不公平的原因其实就是这一段代码，我们把它注释掉，就成为【公平锁】了。

1
2
3
4
5
6
7
8
  public void lock() {
        // 拿到锁直接返回
//        if (flag.compareAndSet(false, true)) {
//            owner = Thread.currentThread();
//            return;
//        }
    ...
  }

8、目前这个版本是存在死锁可能性的。

我们用注释标注几行代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public class MyLock {
    /...../

    public void lock() {
        /...../
        // 没拿到锁的话，则要安全的把自己放在链表上
        Node current = new Node();
        current.thread = Thread.currentThread();
        while (true) {
            Node currentTail = tail.get();
            if (tail.compareAndSet(currentTail, current)) {
                current.prev = currentTail;            //(1)
                currentTail.next = current;
                break;
            }
        }
        /...../

    }

    public void unlock() {
        if (owner != Thread.currentThread()) {
            throw new IllegalStateException("当前线程并不占用锁，不允许释放锁");
        }
        Node headNode = head.get();           //(2)
        flag.set(false);
        if(headNode.next!=null){              //(3)
            LockSupport.unpark(headNode.next.thread);    
        }
    }
    
    /......./

}

假设这样的场景：

有线程A和线程B并发，线程A先抢到了锁，执行完了自己的任务，准备释放锁，此时它在（2）处，还没有执行；

线程B没有抢到锁，所以准备把自己放到等待队列中，此时它在（1）处，没有执行；

此时线程A执行（2）（3）处代码，问题发生了——线程B执行了tail.compareAndSet(currentTail, current)，所以（2）（3）处headNode是存在的；但是线程B没有执行（1）处，所以headNode.next是空，所以线程A不会去唤醒线程B。

线程A完成了lock与unlock，拍拍屁股走了，但是线程B却一直在休眠。

除非有新的线程进来，否则线程B将一直休眠，死锁产生。

怎么解决呢？其实也很简单。

把这段代码改成这样即可：

1
2
3
4
5
6
7
8
9
10
11
12
// 拿到锁的话，要安全的把自己从链表中删除
while (true) {
  	if (head.get().next == current && flag.compareAndSet(false, true)) {
    		owner = Thread.currentThread();
    		head.set(current);
    		current.prev.next = null;
    		current.prev = null;
    		return;
  	}
  	// 休眠
  	LockSupport.park();
}

细品即可。

9、最终版本

总结Lock的本质：状态变量 + 双向链表 + CAS + 自选

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
package safeList;

import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicReference;
import java.util.concurrent.locks.LockSupport;

/**
 * @author Michael
 *
 */

public class MyLock {
    private final AtomicBoolean flag = new AtomicBoolean(false);
    private Thread owner = null;
    private AtomicReference<Node> head = new AtomicReference<>(new Node());
    private AtomicReference<Node> tail = new AtomicReference<>(head.get());

    public void lock() {
        // 拿到锁直接返回（注掉这一段，就变成【公平锁】）
        if (flag.compareAndSet(false, true)) {
            owner = Thread.currentThread();
            return;
        }
        // 没拿到锁的话，则要安全的把自己放在链表上
        Node current = new Node();
        current.thread = Thread.currentThread();
        while (true) {
            Node currentTail = tail.get();
            if (tail.compareAndSet(currentTail, current)) {
                current.prev = currentTail;
                currentTail.next = current;
                break;
            }
        }
        // 拿到锁的话，要安全的把自己从链表中删除
        while (true) {
            if (head.get().next == current && flag.compareAndSet(false, true)) {
                owner = Thread.currentThread();
                head.set(current);
                current.prev.next = null;
                current.prev = null;
                return;
            }
            // 休眠
            LockSupport.park();
        }

    }

    public void unlock() {
        if (owner != Thread.currentThread()) {
            throw new IllegalStateException("当前线程并不占用锁，不允许释放锁");
        }
        Node headNode = head.get();
        flag.set(false);
        if(headNode.next!=null){
            LockSupport.unpark(headNode.next.thread);
        }
    }

    class Node {
        Node prev;
        Node next;
        Thread thread;
    }


}

四、可重入锁

1、可重入锁概念

【可重入锁】指的是：当一个线程获得一把锁时，可再次获得这把锁，而不会发生死锁。

在 Java 中，synchronized 是可重入锁，支持同一个线程多次进入同步代码块。

举例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class ReentrantExample {
    public synchronized void methodA() {
        System.out.println("methodA()");
        methodB();  // 线程已经获取了锁，可以再次进入 methodB()
    }

    public synchronized void methodB() {
        System.out.println("methodB()");
    }

    public static void main(String[] args) {
        ReentrantExample obj = new ReentrantExample();
        obj.methodA();
    }
}

输出：

1
2
methodA()
methodB()

Java 提供的 ReentrantLock 也是可重入锁，允许同一个线程多次获取同一把锁。

其实reentrantLock就翻译为【可重入锁】。

2、什么时候会有一个线程重复获得锁？

  • 方法递归调用
  • 同一个锁保护的多个方法之间的调用（如上）
  • 在一个线程中循环获得锁

3、手写可重入锁MyReentrantLock

核心思路：

1）将 AtomicBoolean flag = new AtomicBoolean(false)改为AtomicInteger state = new AtomicInteger(0)

state描述的是当前【锁被同一个线程获取的次数】。

线程能直接获取锁的条件也就变成了：【锁当前是自由的】或者【锁已经被当前线程获取】

2）在lock()的入口处，修改【线程直接获取锁】的逻辑，支持通过【锁已经被当前线程获取】获取到锁。

1
2
3
4
5
6
7
8
9
10
// 拿到锁直接返回（注掉这一段，就变成【公平锁】）
        if(state.get()==0) {
            if (state.compareAndSet(0, 1)) {
                owner = Thread.currentThread();
                return;
            }
        }else if(owner==Thread.currentThread()){
            state.incrementAndGet();
            return;
        }

3）修改锁的释放逻辑：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public void unlock() {
        if (owner != Thread.currentThread()) {
            throw new IllegalStateException("当前线程并不占用锁，不允许释放锁");
        }
        int i=state.get();
        if(i>1){
            state.set(i-1);
            return;
        }
        if(i<=0){
            throw new IllegalStateException("重入锁 unlock 次数大于 lock 次数！");
        }
        Node headNode = head.get();
        owner=null;                     //(1)
        state.set(0);
        if(headNode.next!=null){
            LockSupport.unpark(headNode.next.thread);
        }
    }

注意（1）处：

  • 在不可重入锁版本中，owner=null没有存在的必要，不过就算加上也不会有错。

  • 在当前可重入锁版本中，owner=null是必须的，否则会有两个线程获取到锁的可能。

    假设可重入场景下，不写owner=null：

    线程A获取到锁，执行完任务后，释放掉锁，但此时 owner 仍指向线程A；

    线程B通过if(state.get()==0)获取到锁，但还没来得及将 owner 指向自己；

    线程A又尝试争抢锁，由于else if(owner==Thread.currentThread())是成立的，所以线程A也获得锁；

    A、B同时获得锁，锁失效。

MyReentrantLock最终版本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
package safeList;

import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicReference;
import java.util.concurrent.locks.LockSupport;

/**
 * @author Michael
 *
 */

public class MyReentrantLock {
    private final AtomicInteger state = new AtomicInteger(0);
    private Thread owner = null;
    private AtomicReference<Node> head = new AtomicReference<>(new Node());
    private AtomicReference<Node> tail = new AtomicReference<>(head.get());

    public void lock() {
        // 拿到锁直接返回（注掉这一段，就变成【公平锁】）
        if(state.get()==0) {
            if (state.compareAndSet(0, 1)) {
                owner = Thread.currentThread();
                return;
            }
        }else if(owner==Thread.currentThread()){
            state.incrementAndGet();
            return;
        }

        // 没拿到锁的话，则要安全的把自己放在链表上
        Node current = new Node();
        current.thread = Thread.currentThread();
        while (true) {
            Node currentTail = tail.get();
            if (tail.compareAndSet(currentTail, current)) {
                current.prev = currentTail;
                currentTail.next = current;
                break;
            }
        }

        // 拿到锁的话，要安全的把自己从链表中删除
        while (true) {
            if (head.get().next == current && state.compareAndSet(0, 1)) {
                owner = Thread.currentThread();
                head.set(current);
                current.prev.next = null;
                current.prev = null;
                return;
            }
            // 休眠
            LockSupport.park();
        }

    }

    public void unlock() {
        if (owner != Thread.currentThread()) {
            throw new IllegalStateException("当前线程并不占用锁，不允许释放锁");
        }
        int i=state.get();
        if(i>1){
            state.set(i-1);
            return;
        }
        if(i<=0){
            throw new IllegalStateException("重入锁 unlock 次数大于 lock 次数！");
        }
        Node headNode = head.get();
        owner=null;
        state.set(0);
        if(headNode.next!=null){
            LockSupport.unpark(headNode.next.thread);
        }
    }

    class Node {
        Node prev;
        Node next;
        Thread thread;
    }


}

测试main函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
package safeList;

public class LockExample {
    public static void main(String[] args) throws InterruptedException {
        int[] count = {100};
        MyReentrantLock myLock=new MyReentrantLock();

        final int NUM=30;
        Thread[] threads=new Thread[NUM];
        for (int i = 0; i < NUM; i++) {
            Thread thread = new Thread(new Runnable() {
                @Override
                public void run() {
                    for(int i=0;i<NUM;i++){
                        myLock.lock();
                        count[0]--;
                        myLock.unlock();
                    }
                }
            });
            threads[i]=thread;
        }

        for (int i = 0; i < NUM; i++) {
            threads[i].start();
        }

        for (int i = 0; i < NUM; i++) {
            threads[i].join();
        }

        System.out.println(count[0]);

    }
}

五、无法理解的BUG

在用上面的测试函数对MyReentrantLock进行测试时，我遇到了这样的情况：

202503140039790.png

它居然显示这里会有空指针异常，我无法理解：

1
2
3
if(headNode.next!=null){
  	LockSupport.unpark(headNode.next.thread);  // 此处 headNode.next
}

更离谱的是，前期试出过几次后，我在程序里循环执行10000次这个测试，但都没有复现！

更离谱的是，当我放弃循环，而是大概手点了50次之后，它又出现了……….

我发誓我没有修改任何一行代码！我发誓上面这张图也不是P图！

但是我隐约觉得这应该不是代码逻辑的问题。。。。

展开全文 >>

coze+laf 天气查询agent-开发文档

[TOC]

天气查询agent-开发文档

使⽤coze + laf 开发⼀个智能体能解决查天⽓场景，⽀持单轮/多轮场景

一、技术栈

  • Coze 用于智能体对话逻辑，实现单轮/多轮交互
  • LAF (云开发平台) 提供云函数、数据库、API 处理天气天气
  • 天气数据（随机生成） 由 LAF 云函数生成模拟天气数据

二、开发

1、laf

laf 是开源的云开发平台，提供云函数、云数据库、云存储等开箱即用的应用资源。

1）注册登录。

2）创建应用，开始编写【查询天气API】

image-20250308163248267

3）函数getWeather()代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
export default async function (ctx: FunctionContext) {
  // 获取请求参数
  const city = ctx.query.city || "未知城市";
  const date = ctx.query.date || "今天";

  // 🌦 可能的天气类型
  const weatherTypes = [
    "晴天", "多云", "阴天", "小雨", "中雨", "大雨", "雷暴", "大雪", "雾霾", "沙尘暴"
  ];

  // 🌡️ 生成温度（最低温 & 最高温）
  const minTemp = Math.floor(Math.random() * 15) + 5;  // 5°C ~ 20°C
  const maxTemp = minTemp + Math.floor(Math.random() * 10) + 5;  // 高温比低温高 5~15°C

  // 🍃 风速 & 风向
  const windSpeeds = ["1级风", "2级风", "3级风", "4级风", "5级风", "6级风"];
  const windDirections = ["东风", "西风", "南风", "北风", "东北风", "西南风", "东南风", "西北风"];

  // 💧 湿度范围（%）
  const humidity = Math.floor(Math.random() * 50) + 30; // 30% ~ 80%

  // 🌫️ 空气质量
  const airQualityLevels = ["优", "良", "轻度污染", "中度污染", "重度污染"];
  const airQuality = airQualityLevels[Math.floor(Math.random() * airQualityLevels.length)];

  // 📅 生成24小时的天气数据
  const hours = [
    { time: "06:00", weather: "晴天", temperature: `${minTemp}°C ~ ${maxTemp}°C`, wind: `${windSpeeds[0]} ${windDirections[0]}`, humidity: `${humidity}%`, airQuality },
    { time: "09:00", weather: weatherTypes[Math.floor(Math.random() * weatherTypes.length)], temperature: `${minTemp + 2}°C ~ ${maxTemp + 2}°C`, wind: `${windSpeeds[1]} ${windDirections[2]}`, humidity: `${humidity + 5}%`, airQuality },
    { time: "12:00", weather: weatherTypes[Math.floor(Math.random() * weatherTypes.length)], temperature: `${minTemp + 5}°C ~ ${maxTemp + 5}°C`, wind: `${windSpeeds[2]} ${windDirections[3]}`, humidity: `${humidity + 10}%`, airQuality },
    { time: "14:00", weather: weatherTypes[Math.floor(Math.random() * weatherTypes.length)], temperature: `${minTemp + 6}°C ~ ${maxTemp + 6}°C`, wind: `${windSpeeds[3]} ${windDirections[4]}`, humidity: `${humidity + 15}%`, airQuality },
    { time: "18:00", weather: weatherTypes[Math.floor(Math.random() * weatherTypes.length)], temperature: `${minTemp + 4}°C ~ ${maxTemp + 4}°C`, wind: `${windSpeeds[4]} ${windDirections[5]}`, humidity: `${humidity + 20}%`, airQuality },
    { time: "21:00", weather: weatherTypes[Math.floor(Math.random() * weatherTypes.length)], temperature: `${minTemp + 1}°C ~ ${maxTemp + 1}°C`, wind: `${windSpeeds[1]} ${windDirections[6]}`, humidity: `${humidity + 25}%`, airQuality }
  ];

  // 📌 组合天气信息
  const weatherInfo = {
    city,
    date,
    hours
  };

  return {
    status: "success",
    data: weatherInfo
  };
}

4）右上角点击发布，得到 【API 调用URL】：https://APPID.laf.run/getWeather。

2、Coze

无论你是否有编程基础，你都可以在扣子平台快速搭建一个 AI 智能体。官方文档

1）进入 coze 官网，注册登录，点击 -》创建 -》创建智能体。

2）开发页面

无标题

主要用到这四个部分：

1.人设与回复逻辑

智能体的人设与回复逻辑定义了智能体的基本人设，此人设会持续影响智能体在所有会话中的回复效果。建议在人设与回复逻辑中指定模型的角色、设计回复的语言风格、限制模型的回答范围，让对话更符合用户预期。

  • 人设：天气AI助手相关人设，可自定义风格。（过于长，截图中有展示，这里不贴）
  • 回复逻辑：
    1. 回复时，结合历史对话信息。
    2. 从用户的输入中，分析出参数 city 和参数 date 从用户的输入中，分析出参数 city 和参数 date。（用户可能一次查询多天的数据，请仔细分析，每查询一天都要经历下面的步骤，即下面步骤可能重复进行）
    3. 如果历史对话中有相似的查询记录（例如：已经查过了北京-3月8号，现在又查询今天（3月8号）的北京天气），则按照已查询的结果返回给用户即可。
    4. 如果没有相似的记录，则还要分析用户传入的时间是否合理，例如：用户查询距今一年之后的天气是完全不合理的，应该提示用户重新输入；查询距今一年以前的数据认为是合理的。
    5. 如果没有问题，将这两个参数传入到工作流【weatherPredict】中，工作流会返回格式化的查询结果。
    6. 查询结果中包含时间、天气、气温等等，请用格式化的形式，并结合上述人设，清晰、分层次的回复用户。
    7. 如有必要，调用插件【必应搜索】，但是注意：天气数据以工作流返回的数据为准。

2.技能

如果模型能力可以基本覆盖智能体的功能，则只需要为智能体编写提示词即可。但是如果你为智能体设计的功能无法仅通过模型能力完成，则需要为智能体添加技能，拓展它的能力边界。

在这里，添加了自定义的工作流【weatherPredict】，用于调用 laf 平台提供的API：

shapes at 25-03-08 16.22.24

  • 增加一个 HTTP 请求节点，三个节点的参数传递联通。
  • HTTP节点：
    • URL：填写laf提供的【API地址】：https://APPID.laf.run/getWeather
    • 请求参数：city date

3.对话

可在这里显示智能体提供方信息。

4.预览与调试

实时可与智能体 agent 进行对话，调试设计效果。

三、最终效果

  1. 单日多轮次查询（先查询天气，后问是否适合骑行，前后逻辑一致）。

  2. 重复地点日期的查询结果一致。

  3. 太久以后的天气查询不合理，提示不会查询。

  4. 过往天气允许查询。

  5. 可一次查询三天内数据。

  6. 用户输入中缺少【地点】或【天气】时，提示用户。

  7. 不同地点天气数据可对比。

image-20250308162650013

image-20250308162714738

image-20250308162748875

image-20250308164703578

image-20250308170302514

image-20250308164727398

四、优化

1、连续多天查询

测试发现，当用户输入【查询未来连续三天天气】，模型可正常工作；但当查询【未来一周天气变化】时，模型提示操作失败：

image-20250308174100701

这是因为之前的多天查询是通过【循环调用工作流】实现的；现在进行优化，将【循环转移到工作流内部】实现多天查询。

  1. 重新定义工作流输入参数类型：

    • city
    • dateList

  2. 新增工作流节点——循环节点，将HTTP请求放在循环体内部循环调用。另外用一个输出节点展示查询过程。

  3. 增加一个【大模型节点】，整理总结循环体返回的结构化数据。

image-20250308204514922

  1. 测试运行结果：

    image-20250308204950105

2、天气数据生成折线图

引入插件【图表大师】

3、新建【天气数据格式】知识库，保证回复内容的格式稳定

image-20250308211226404

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
## 📍 北京 2025-03-08 天气预报

| 时间段 | 天气状况 | 气温 🌡️ | 风速 💨 | 湿度 💧 | 其他信息 |
|------------|--------------|---------|---------|---------|---------|
| 00:00 - 03:00 | 🌙 晴朗 | 5°C | 2m/s 东风 | 60% | 夜晚微凉，适合睡觉 😴 |
| 03:00 - 06:00 | 🌫️ 多云 | 4°C | 1m/s 东风 | 65% | 轻雾，开车注意安全 🚗 |
| 06:00 - 09:00 | ⛅ 阴天 | 7°C | 3m/s 东南风 | 70% | 适合晨跑 🏃‍♂️ |
| 09:00 - 12:00 | ☀️ 晴天 | 15°C | 5m/s 南风 | 50% | 太阳出来啦，戴墨镜🕶️ |
| 12:00 - 15:00 | 🔥 炎热 | 23°C | 6m/s 西南风 | 40% | 多喝水！避免中暑 🥤 |
| 15:00 - 18:00 | 🌤️ 多云 | 20°C | 4m/s 西风 | 55% | 下午微风拂面 🍃 |
| 18:00 - 21:00 | 🌧️ 小雨 | 14°C | 3m/s 东风 | 75% | 出门记得带伞 ☂️ |
| 21:00 - 00:00 | ⛈️ 雷阵雨 | 10°C | 7m/s 北风 | 80% | 雷雨天注意安全 ⚡ |

---

## 📌 未来 3 天趋势
1
2
3
4
5
6
7
8
9
10
11
12
13
| 日期 📅 | 最高气温 🌡️ | 最低气温 ❄️ | 天气状况 ⛅ | 风速 💨 | 适宜活动 🎯 |
|---------|------------|------------|------------|---------|------------|
| 03-09 (周日) | 22°C | 10°C | ⛅ 阴天 | 5m/s | 适合外出游玩 🎡 |
| 03-10 (周一) | 18°C | 8°C | 🌧️ 小雨 | 6m/s | 记得带伞 ☂️ |
| 03-11 (周二) | 12°C | 3°C | 🌨️ 大雪 | 8m/s | 室内活动更佳 🏠 |

---

### ✨ 额外信息
✅ **紫外线指数**：🌞 中等，外出需防晒
✅ **空气质量指数**：💨 良好（AQI 50），适合户外活动
✅ **日出 / 日落**：🌅 06:30 / 🌇 18:10

3、还可以引入语音与文本互转的插件

4、Laf 层可以增加多个天气数据源，提高稳定性

示例代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
import cloud from "@lafjs/cloud";

/**
 * 🌍 多 API 兜底，优先使用外部 API，失败时返回随机天气数据
 */
async function getWeatherFromAPIs(city: string, date: string) {
  const apiList = [
    `https://api.weather1.com/query?city=${encodeURIComponent(city)}&date=${date}`,
    `https://api.weather2.com/weather?location=${encodeURIComponent(city)}&day=${date}`,
    `https://api.weather3.com/v1/weather?place=${encodeURIComponent(city)}&date=${date}`,
  ];

  for (const api of apiList) {
    try {
      const response = await cloud.fetch(api);
      if (response.status >= 200 && response.status < 300) {  // ✅ 正确的状态检查
        const data = response.data;
        return data;
      }

    } catch (error) {
      console.warn(`⚠️ API 请求失败: ${api}`, error);
    }
  }

  // 所有 API 失败，返回模拟数据
  return generateMockWeatherData(city, date);
}

/**
 * 🛠️ 生成随机天气数据（API 兜底）
 */
function generateMockWeatherData(city: string, date: string) {
  const weatherTypes = ["☀️ 晴天", "⛅ 多云", "🌧️ 小雨", "⛈️ 雷暴", "❄️ 大雪", "🌫️ 雾霾"];
  const windSpeeds = ["1级风", "2级风", "3级风", "4级风", "5级风"];
  const windDirections = ["东风", "西风", "南风", "北风", "东北风", "西南风"];

  const minTemp = Math.floor(Math.random() * 10) + 5; // 5°C ~ 15°C
  const maxTemp = minTemp + Math.floor(Math.random() * 10) + 5; // +5 ~ 15°C
  const humidity = Math.floor(Math.random() * 50) + 30; // 30% ~ 80%
  const airQualityLevels = ["优", "良", "轻度污染", "中度污染", "重度污染"];
  const airQuality = airQualityLevels[Math.floor(Math.random() * airQualityLevels.length)];

  const hours = ["06:00", "09:00", "12:00", "15:00", "18:00", "21:00"].map((time) => ({
    time,
    weather: weatherTypes[Math.floor(Math.random() * weatherTypes.length)],
    temperature: `${minTemp + Math.floor(Math.random() * 5)}°C ~ ${maxTemp + Math.floor(Math.random() * 5)}°C`,
    wind: `${windSpeeds[Math.floor(Math.random() * windSpeeds.length)]} ${windDirections[Math.floor(Math.random() * windDirections.length)]}`,
    humidity: `${humidity + Math.floor(Math.random() * 20)}%`,
    airQuality,
  }));

  return {
    city,
    date,
    today: { minTemp, maxTemp, airQuality },
    hours,
    forecast: generateFutureWeather(city),
  };
}

/**
 * 📅 生成未来 3 天的天气预报
 */
function generateFutureWeather(city: string) {
  const weatherTypes = ["☀️ 晴天", "🌧️ 小雨", "⛈️ 雷暴", "❄️ 大雪", "🌫️ 雾霾"];
  return [...Array(3)].map((_, i) => {
    const minTemp = Math.floor(Math.random() * 10) + 5;
    const maxTemp = minTemp + Math.floor(Math.random() * 10) + 5;
    return {
      date: `+${i + 1} 天`,
      weather: weatherTypes[Math.floor(Math.random() * weatherTypes.length)],
      temperature: `${minTemp}°C ~ ${maxTemp}°C`,
    };
  });
}

/**
 * 📌 主入口
 */
export default async function (ctx: FunctionContext) {
  const city = ctx.query.city || "未知城市";
  const date = ctx.query.date || "今天";

  // 🌍 查询天气数据（API + 兜底）
  const weatherData = await getWeatherFromAPIs(city, date);

  // 📊 返回 Markdown 格式化数据
  return {
    status: "success",
    data: weatherData,
    markdown: generateMarkdown(weatherData),
  };
}

/**
 * 📊 生成 Markdown 格式天气信息
 */
function generateMarkdown(weatherData: any) {
  const { city, date, today, hours, forecast } = weatherData;

  let md = `## 📍 ${city} - ${date} 天气预报\n\n`;
  md += `🌡 **温度:** ${today.minTemp}°C ~ ${today.maxTemp}°C  \n`;
  md += `💨 **空气质量:** ${today.airQuality}  \n\n`;

  md += `### ⏳ 今日分时天气\n\n`;
  md += `| 时间 ⏰ | 天气 ☁️ | 温度 🌡 | 风 🌬 | 湿度 💧 | 空气质量 🍃 |\n`;
  md += `|--------|--------|--------|--------|--------|--------|\n`;
  hours.forEach((h: any) => {
    md += `| ${h.time} | ${h.weather} | ${h.temperature} | ${h.wind} | ${h.humidity} | ${h.airQuality} |\n`;
  });

  md += `\n### 📅 未来 3 天天气预报\n\n`;
  md += `| 日期 📆 | 天气 ⛅ | 温度 🌡 |\n`;
  md += `|--------|--------|--------|\n`;
  forecast.forEach((f: any) => {
    md += `| ${f.date} | ${f.weather} | ${f.temperature} |\n`;
  });

  return md;
}

新 API getWeatherPro测试结果：

image-20250308212147183

展开全文 >>

伙伴匹配项目-readme

[TOC]

伙伴匹配项目-readme

项目关键词：标签、帮助找到志同道合的朋友、移动端H5网页。

沿用 用户中心项目 的后端，增加新功能。

新建一个移动端的前端项目。

需求分析

  1. 用户标签：每个用户给自己打上标签，标签有种类、分类
  2. 主动搜索其他用户（根据标签）
    1. Redis缓存
  3. 组队：
    1. 创建队伍
    2. 加入队伍
    3. 根据标签查询
    4. 邀请加入
  4. 推荐
    1. 相似度计算算法 + 本地分布式计算

技术栈

前端

  1. Vue3 开发框架
  2. Vant UI（基于Vue的移动端组件库）
  3. Vite（初始化工具，打包工具）
  4. Nginx 来单机部署

后端

  1. Springboot
  2. SpringMVC + Mybatis + Mybatis-plus
  3. MySQL
  4. Redis 缓存库
  5. Swagger + Knife4j 接口文档

Vue 与 Vue Router 的知识点

将开发过程中学习到的有关 Vue 和 Vant 的知识点集中写在这里

Vue

  1. 响应式API：ref 与 computed简单介绍：

    • ref()：接受一个内部值，返回一个可读可写的响应式对象（响应式对象下面简写为 ref 对象）

    • computed()：接受一个 getter 函数，返回一个只读的 ref 对象。

    • 传进去的数据data保存在 ref 对象的.value中，在 js 中使用 .value 属性来访问数据，但是在 template 中，不需要加上.value，ref 对象会自动解包。

    • ref 与 computed 的区别：如果传进来的内部值也是一个响应式对象，那么：

      • ref()返回的 ref 对象不会随内部值的变化而更新
      • computed()返回的 ref 对象会随内部值的变化而更新

    • 示例：创建一个布尔属性 ref 对象 show

      1
      const show = computed(() => list.includes(route.fullPath));

      这里 route.fullPath 也是一个响应式对象，

      computed 的特点就是实时追踪内部响应式的状态并更新返回数据。

      相比之下，ref 仅仅是赋一个初始值，如果写成：

      1
      const show = ref(list.includes(route.fullPath))

      那么 show 的值将不会随 route.fullPath 的值变化而更新。

Vue Router

  1. 两个核心对象：

    • 路由器实例：const router=useRouter();
    • 当前路由：const route=useRoute();

  2. router.push()的params与query

    • params是构建动态路由相关的参数：

      1
      router.push({ name: 'user', params: { username: 'eduardo' } })  //结果是：/user/eduardo

    • query是路径传参相关的参数：

      1
      router.push({ path: '/register', query: { plan: 'private' } })  //结果是：/register?plan=private

前端初始化

**Vite **是一种新型的前端构建工具，支持快速构建不同类型的前端脚手架，例如：React、Vue等等

使用 Vite 参考官方文档。

版本选择：该项目选择对应Vue3的版本。

Vant UI

  1. 参考官方文档，安装 Vant。

  2. 引入 Vant

    Vant 组件有多种引入方式：

    • 全局引入、局部引入
    • 全量引入、按需引入

  3. 开发时选择全局全量引入，方便开发。优化项目体积时再改成按需引入。

前端开发

页面开发 | 通用布局

很多页面有通用的样式，重复写会很麻烦，所以需要抽象一个通用布局

设计

导航条：展示当前页面名称

首页有搜索框 => 搜索页（含标签项）

tab栏

  • 主页（推荐页+广告）

    • 搜索框
    • banner
    • 推荐信息流

  • 队伍页

  • 用户页

开发

  1. 新建目录src/layouts用于存放样式。

  2. 通用布局：layouts/BasicLayout.vue

    1. 引入组件NavBar：导航栏
    2. 引入组件Tabbar：标签栏
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    <template>

    <van-nav-bar title="标题" left-text="返回" left-arrow @click-left="onClickLeft"
                 @click-right="onClickRight">
      <template #right>
        <van-icon name="search" size="18" />
    </template>
    </van-nav-bar>


    <van-tabbar v-model="active" @change="onChange">
      <van-tabbar-item name="index" icon="home-o">主页</van-tabbar-item>
      <van-tabbar-item name="team" icon="search">队伍</van-tabbar-item>
      <van-tabbar-item name="user" icon="friends-o">个人</van-tabbar-item>
    </van-tabbar>

    </template>

  3. 写几个简单页面供使用：

    • src/pages/Index.vue

    • src/pages/Team.vue

    • src/pages/User.vue

  4. 用<v-if>实现页面切换，试试效果:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    <div id="content">
      <template v-if="active === 'index'">
    <Index />
      </template>
      <template v-if="active === 'team'">
    <Team />
      </template>
      <template v-if="active === 'user'">
    <User />
      </template>
    </div>

  5. BasicLayout.vue代码：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    <script setup >
      import { ref } from 'vue'
      import Index from "../pages/Index.vue";
      import Team from "../pages/Team.vue";
      import Index from "../pages/User.vue";
      const onClickLeft = () => alert("左");
      const onClickRight = () => alert("右")
      const active = ref('index');
      const onChange = (index) => showToast(`标签 ${index}`);
    </script>

    <template>
    <van-nav-bar title="标题" left-text="返回" left-arrow @click-left="onClickLeft"
                 @click-right="onClickRight">
      <template #right>
        <van-icon name="search" size="18" />
    </template>
    </van-nav-bar>

    <div id="content">
      <template v-if="active === 'index'">
    <Index />
      </template>
      <template v-if="active === 'team'">
    <Team />
      </template>
      <template v-if="active === 'user'">
    <User />
      </template>
    </div>

    <van-tabbar v-model="active" @change="onChange">
      <van-tabbar-item name="index" icon="home-o">主页</van-tabbar-item>
      <van-tabbar-item name="team" icon="search">队伍</van-tabbar-item>
      <van-tabbar-item name="user" icon="friends-o">个人</van-tabbar-item>
    </van-tabbar>

    </template>

    <style scoped>
    </style>

  6. 效果：

    image-20250130221312398

引入前端路由

**Vue Router **是 Vue 官方的客户端路由解决方案。

客户端路由的作用是：在单页应用 (SPA) 中将浏览器的 URL 和用户看到的内容绑定起来。当用户在应用中浏览不同页面时，URL 会随之更新，但页面不需要从服务器重新加载，而是根据不同的 URL 展示不同的内容。

在上一节，使用的是原始的<v-if>实现页面的切换，现在使用 Vue Router 优化页面切换：

  1. 安装 Vue Router

  2. 在main.ts中引入路由器，为Index Search User组件配置路由

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    import { createMemoryHistory, createRouter } from 'vue-router'

    import Index from "../pages/Index.vue";
    import Team from "../pages/Team.vue";
    import User from "../pages/User.vue";

    const routes = [
      { path: '/index', component: Index },
      { path: '/team', component: Team },
      { path: '/user', component: User },
    ]

    const router = createRouter({
      history: createMemoryHistory(),
      routes,
    })

    const app = createApp(App)
    app.use(router)
    app.mount('#app')

  3. 将上面的路由配置提出来，创建src/config/routes.ts专门配置路由：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    import Index from "../pages/Index.vue";
    import Team from "../pages/Team.vue";
    import User from "../pages/User.vue";

    const routes = [
      { path: '/index',name='index', component: Index },
      { path: '/team', name='team',component: Team },
      { path: '/user', name='user',component: User },
    ]

    export default routes

  4. 在main.ts引用routes.ts：import routes from "./config/routes.ts";

  5. 标签栏Tabbar支持有专门支持 Vue Router 的模式 :

    1
    2
    3
    4
    5
    6
    7
    8
    9
    <div>
      <RouterView />
    </div>

    <van-tabbar route>
      <van-tabbar-item replace to="/index" icon="home-o">index</van-tabbar-item>
      <van-tabbar-item replace to="/team" icon="search">team</van-tabbar-item>
      <van-tabbar-item replace to="/user" icon="user">user</van-tabbar-item>
    </van-tabbar>
    • to：点击标签，会自动匹配路径下的组件
    • <RouterView>：组件的显示区域

    如果 Vant 组件没有专门支持 Vue Router，则需要使用 Vue Router 的常规用法，如<RouterLink> router.push() 等。

    具体参考官方文档。

  6. 优化后的BasicLayout.vue代码：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    <script setup>
    import {ref} from 'vue'
    import {useRoute, useRouter} from 'vue-router'
    import { computed } from 'vue';

    // router 与 route 都是响应式数据
    const router = useRouter();
    const route = useRoute();
    // ref() :将数据声明为一个响应式数据，并赋以默认值。详细可查看官方文档
    const active = ref('index');
    // computed()：自动响应内部响应式数据的变化，并返回一个响应式数据
    const list = ['/index','/team','/user'];
    const show = computed(() => list.includes(route.fullPath));
    const onChange = (index) => showToast(`标签 ${index}`);
    const onClickLeft = () => router.back();
    const onClickRight = () => router.push('/search')
    </script>

    <template>
      <van-nav-bar title="标题" left-text="返回" :left-disabled="show" left-arrow @click-left="onClickLeft"
                   @click-right="onClickRight">
        <template #right>
          <van-icon name="search" size="18"/>
        </template>
      </van-nav-bar>

      <div>
        <h1>Hello App!</h1>
        <main>
          <RouterView />
        </main>
      </div>

      <van-tabbar v-model="active" route @change="onChange">
        <van-tabbar-item replace to="/index" icon="home-o">index</van-tabbar-item>
        <van-tabbar-item replace to="/team" icon="search">team</van-tabbar-item>
        <van-tabbar-item replace to="/user" icon="user">user</van-tabbar-item>
      </van-tabbar>

    </template>

    <style scoped>
    </style>

页面开发 | 搜索页面

根据标签搜索用户 Search.vue

设计

选用：搜索框Search + 标签 Tag+ 分类选择TreeSelect

  • 搜索框在顶部：Search
  • 中间是已选标签列：Tag
  • 下面是可供选择的标签：TreeSelect

开发

  1. 引入组件：
    • Search
    • Tag
    • TreeSelect
  2. 主要逻辑：
    1. 可以在搜索框Search中直接搜索标签关键字
    2. 也可以在分类选择TreeSelect中选择标签关键字
    3. 列出选中的标签
    4. 点击按钮发送搜索请求
    5. 收到返回，跳转到搜索结果页面

页面开发 | 搜索结果页面

页面开发 | 用户信息页

设计

Cell单元格

开发

  1. 引入组件
  2. 主要逻辑：
    1. 展示信息
    2. 点击信息项可进行编辑

页面开发 | 用户信息编辑页面

设计

选用：Form表单

页面开发 | 登录页面

Pinia | 维护用户登录态

Vue 可以用响应式 API reactive() 做简单状态管理：如果你有一部分状态需要在多个组件实例间共享，你可以使用 reactive()来创建一个响应式对象，并将它导入到多个组件。

另外，官方文档介绍了 pinia 作为大规模应用下的状态管理工具，出于学习目的，在这里大材小用一下，引入 pinia 进行用户登录状态管理：

  1. 安装 pinia 。

  2. 定义用户登录状态useUserStateStore，这个Store可以在全局每个组件中通过const userState=useUserStateStore()引用：

    currentUser就是维护的数据，他是一个 ref 对象。

    queryCurrentUser()和logout()是数据相关的方法。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    export const useUserStateStore = defineStore('userState', () => {
      const currentUser = ref<UserType | null>(null);
      async function queryCurrentUser() {
        const response = await getCurrentUser();
        currentUser.value = response.data;
        console.log(currentUser.value);
      }
      function logout() {
        console.log("正在清空session");
        // 删除浏览器中的 cookie
        currentUser.value = null;
      }
      return {currentUser, queryCurrentUser, logout}
    })

  3. Axios 默认，发生跨域请求时，请求不会携带 cookie，这里配置开启 cookie。

    src/plugins/myAxios.ts：

    1
    2
    3
    4
    5
    6
    7
    8
    import axios from 'axios';
    const myAxios = axios.create({
        baseURL: 'http://localhost:8080/api',
    })
    // 全局设置允许跨域携带cookie
    myAxios.defaults.withCredentials = true;

    export default myAxios;

  4. 此时就有了一个可以全局共享的用户状态userState，还用 cookie 维护了用户的登录态。

    在用户登录后，调用queryCurrentUser()来向后端获取当前用户信息，并保存在currentUser中。

    在其他组件中获取用户登录态：

    1
    2
    3
    4
    5
    6
    7
    8
    <script>
      const userState=useUserStataStore();
    </script>
    <template>
    {{userState.currentUser.userAccount}}
    </template>
    <style>
    </style>

路由导航守卫

完成登录功能以及维护用户登录态后，所有未登录的访问全部跳转到登录页

src/main.ts：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// 代码省略
const router = createRouter({
  history: createMemoryHistory(),
  routes,
})
const pinia=createPinia();
app.use(pinia);
const userState = useUserStateStore();
// 前置路由守卫
router.beforeEach(async (to, from) => {
  await userState.queryCurrentUser();
  if (
    // 检查用户是否已登录
    userState.currentUser=== null &&
    // ❗️ 避免无限重定向
    to.name !== 'login'
  ) {
    // 将用户重定向到登录页面
    showToast("请先登录");
    return {name: 'login'}
  }
  console.log("去往组件："+to.name);
})
// 代码省略

页面开发 | 主页（推荐页）

后端开发

数据库设计

tags表

性别：男、女

语言：java、C++、python、go

正在学：Spring、Mybatis、SpringCloud

目标：考研、求职、竞赛、考公、秋招、春招、社招

段位：初级、中级、高级

身份：大一、大二、大三、大四、学生、待业、研究生

状态：乐观、emo、单身、有对象

【用户自定义标签】

字段：

  1. id int
  2. 标签名 varchar 非空
  3. 上传标签的用户 userId int
  4. 父标签 parentId int
  5. 是否为父标签 isParent tinyint
  6. 创建时间，更新时间，是否删除、

user表

沿用“用户中心项目”的user表

若应用于该项目，有两种选择：

  1. 建立一张关联表，记录user与tags的映射关系
    • 优点：查询灵活、可以正查反查
    • 缺点：要新建一个关联表、维护这个表
  2. 在user表中加入tags字段，类型为varchar,存储内容的格式为JSON格式：['java','c++']
    • 优点：查询方便、不需要新建关联表、且标签也是用户的一个常用属性，可能适用于多个项目
    • 缺点：需要修改用户表

选择方案二：企业开发中会尽量减少关联查询，这既影响扩展性，也影响查询性能

修改并沿用“用户中心项目”的user表

Mybatis-plus

开启设置，会打印出每次查询执行的SQL语句，有助于学习

1
2
3
4
5
#mybatis-plus配置控制台打印完整带参数SQL语句
mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

优化

  1. 给tagName加上唯一索引，加快查询

Java8 StreamAPI

在 Java 8 中，Stream API 提供了一种函数式编程风格来处理集合数据，避免繁琐的循环，提高代码的可读性和可维护性。

  1. map：映射

    1
    2
    3
    List<User> safeUserList=return list.stream().map(user -> {
      return this.makeSafeUser(user);
    }).collect(Collectors.toList());
    1
    List<User> safeUserList=users.stream().map(this::makeSafeUser).collect(Collectors.toList());
    1
    2
    3
    4
    5
    List<String> names = Arrays.asList("Alice", "Bob");
    List<Integer> nameLengths = names.stream()
      .map(String::length)
      .collect(Collectors.toList());
    System.out.println(nameLengths); // 输出: [5, 3]

  2. filter：筛选

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    List<User> list=userList.stream().filter(user -> {
      String tagStr=user.getTags();
      List<String> tempTagNameList=gson.fromJson(tagStr,new TypeToken<String>(){}.getType());
      for(String tagName:tagNameList){
        if(!tempTagNameList.contains(tagName)){
          return false;
        }
      }
      return true;
    }).collect(Collectors.toList());

  3. distinct：去重

  4. sorted：排序

  5. 上述方法也可以组合使用：filter+map

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    List<User> list=userList.stream().filter(user -> {
      String tagStr=user.getTags();
      List<String> tempTagNameList=gson.fromJson(tagStr,new TypeToken<String>(){}.getType());
      for(String tagName:tagNameList){
        if(!tempTagNameList.contains(tagName)){
          return false;
        }
      }
      return true;
    }).map(this::makeSafeUser).collect(Collectors.toList());

关于Stream的并行能力：ParellelStream

https://blog.csdn.net/lsx2017/article/details/105749984

配置跨域请求

新建配置类：com/michael/usercenter/config/WebMvcConfig

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
package com.michael.usercenter.config;

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

/**
 * 配置允许跨域访问的前端域名
 */
@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        // 允许所有源的请求
        registry.addMapping("/**")
                .allowedOrigins("http://localhost:5173") // 允许的前端地址
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") // 允许的请求方式
                .allowedHeaders("*") // 允许的请求头
                .allowCredentials(true); // 允许携带凭证
    }
}

功能开发 | 搜索用户

选择标签，搜索符合的用户。

  1. 根据标签搜索用户，分为两种情况：

    • 允许输入多个标签，多个标签全部存在才能搜索出来
    • 允许输入多个标签，只要有一个标签存在就能搜索出来（to do）

  2. 具体实现方式有两种：SQL查询与内存查询，两种方式的性能表现有差异：

    • SQL查询：将条件写到SQL语句当中，直接进行筛选

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      public List<User> selectUserByTag(List<String> tagNameList) {
        if (CollectionUtils.isEmpty(tagNameList)) {
            throw new BusinessException(ErrorCode.PARAM_NULL);
        }
        QueryWrapper<User> queryWrapper = new QueryWrapper<>();
        for (String tagName : tagNameList) {
          queryWrapper = queryWrapper.like("tags", tagName);
        }
        List<User> users = userMapper.selectList(queryWrapper);
        if (users == null) {
          throw new BusinessException(ErrorCode.UNKNOWN_ERROR);
        }
        return users.stream().map(this::makeSafeUser).collect(Collectors.toList());

      }

    • 内存查询：先将所有用户加载到内存当中，再根据条件进行筛选

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      public List<User> selectUserByTag(List<String> tagNameList) {
        if (CollectionUtils.isEmpty(tagNameList)) {
          throw new BusinessException(ErrorCode.PARAM_NULL);
        }
        QueryWrapper<User> queryWrapper = new QueryWrapper<>();
        List<User> userList=userMapper.selectList(queryWrapper);
        Gson gson=new Gson();
        return userList.stream().filter(user -> {
          String tagStr=user.getTags();
          List<String> tempTagNameList=gson.fromJson(tagStr,new TypeToken<List<String>>(){}.getType());
          for(String tagName:tagNameList){
            if(!tempTagNameList.contains(tagName)){
              return false;
            }
          }
          return true;
        }).map(this::makeSafeUser).collect(Collectors.toList());
      }

      GSON：解析json字符串的类库

性能测试 | 搜索用户 | 并发搜索

可以通过实际运行测试两种查询的消耗时间来比较性能：

1
2
3
4
5
long startTime = System.currentTimeMillis();
/**
 * 测试的方法
*/
log.info("运行耗时："+(System.currentTimeMillis()-startTime));

测试细节：

  1. 设计数据库连接时，数据库第一次连接也需要时间，需要排除这个耗时

  2. 如果多次测试，并没有哪种方式的性能总是占优，则：

    1. 如果参数可以分析，则根据参数去选择查询方式，比如标签数

    2. 如果参数不能分析，且数据库连接足够，内存空间足够，则可以同时并发两种查询，谁先返回用谁。

      并发用到 CompleTableFuture ，下面有提到。

      实现代码：

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      public List<User> selectUserByTag(List<String> tagNameList) {
        //创建内存查询任务
        CompletableFuture<List<User>> listCompletableFuture1 = CompletableFuture.supplyAsync(() -> this.selectUserByTagByMemory(tagNameList));
        //创建SQL查询任务
        CompletableFuture<List<User>> listCompletableFuture2 = CompletableFuture.supplyAsync(() -> this.selectUserByTagBySQL(tagNameList));
        //执行，如果无需打印，则直接返回anyOf的结果
        CompletableFuture<Object> objectCompletableFuture = CompletableFuture.anyOf(listCompletableFuture1, listCompletableFuture2) .thenApply(res -> {
          if (res == listCompletableFuture1.getNow(null)) {
            log.info("memory completed first");
          } else {
            log.info("SQL completed first");
          }
          return res;
        });
        List<User> userList=null;
        try {
          userList= (List<User>)objectCompletableFuture.get();
        } catch (Exception e) {
          throw new BusinessException(ErrorCode.UNKNOWN_ERROR);
        }
        if(userList!=null){
          return userList.stream().map(this::makeSafeUser).collect(Collectors.toList());
        }
        throw new BusinessException(ErrorCode.UNKNOWN_ERROR);
      }

接口文档 | Knife4j（Swagger）

Knife4j是一个集成了swagger的增强解决方案

后端整合Knife4j 自动化生成接口文档，并且还提供了 Http 测试工具

版本：Spingboot2.6.X Knife4j3.0.3

集成knife4j的bug很多是版本问题，参考此处时尽量保持版本一致

  1. 引入依赖：knife4j是一个集成了swagger的增强解决方案

    1
    2
    3
    4
    5
    <dependency>
      <groupId>com.github.xiaoymin</groupId>
      <artifactId>knife4j-spring-boot-starter</artifactId>
      <version>3.0.3</version>
    </dependency>

  2. SwaggerConfig配置类：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    @EnableKnife4j
    @Configuration
    @EnableSwagger2
    @Import(BeanValidatorPluginsConfiguration.class)
    public class SwaggerConfig {

      private static final String SWAGGER_TITLE = "XXX项目 API 接口文档";
      private static final String VERSION = "3.0.3";

      @Bean
      public Docket createRestApi() {
        return new Docket(DocumentationType.OAS_30)
          .enable(true)
          .apiInfo(apiInfo())
          .groupName("3.X 版本")
          .select()
          .apis(RequestHandlerSelectors.withClassAnnotation(RestController.class))
          .paths(PathSelectors.any())
          .build();
      }

      private ApiInfo apiInfo() {
        return new ApiInfoBuilder()
          .title(SwaggerConfig.SWAGGER_TITLE)
          .description("# XXX项目API接口文档简介")
          .termsOfServiceUrl("http://127.0.0.1/#/login")
          .contact(new Contact("michael", "", ""))
          .version(SwaggerConfig.VERSION)
          .build();
      }
    }

    • 定义需要生成接口文档的代码位置：

      1. 只有在指定包下的代码才生成接口文档

        .apis(RequestHandlerSelectors.basePackage("com.michael.controller"))

      2. 只有类上有注解@RestController的才生成接口文档

        .apis(RequestHandlerSelectors.withClassAnnotation(RestController.class))

      3. 只有方法上有注解@ApiOperation的才生成接口文档

        .apis(RequestHandlerSelectors.withMethodAnnotation(ApiOperation.class))

    • @EnableKnife4j @EnableSwagger2 @Import(BeanValidatorPluginsConfiguration.class)

      这三个注解可能没什么用，可以试试删除

  3. 在上面的配置类中加入这一段（因为不清楚这段代码的作用，所以单独列出，可能可以删除）

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    @Bean
    public static BeanPostProcessor springfoxHandlerProviderBeanPostProcessor() {
      return new BeanPostProcessor() {
        @Override
        public Object postProcessAfterInitialization(@NotNull Object bean, @NotNull String beanName) throws BeansException {
          if (bean instanceof WebMvcRequestHandlerProvider || bean instanceof WebFluxRequestHandlerProvider) {
            customizeSpringfoxHandlerMappings(getHandlerMappings(bean));
          }
          return bean;
        }

        private <T extends RequestMappingInfoHandlerMapping> void customizeSpringfoxHandlerMappings(List<T> mappings) {
          List<T> copy = mappings.stream()
            .filter(mapping -> mapping.getPatternParser() == null)
            .collect(Collectors.toList());
          mappings.clear();
          mappings.addAll(copy);
        }

        @SuppressWarnings("unchecked")
        private List<RequestMappingInfoHandlerMapping> getHandlerMappings(Object bean) {
          try {
            Field field = ReflectionUtils.findField(bean.getClass(),"handlerMappings");
            assert field != null;
            field.setAccessible(true);
            return (List<RequestMappingInfoHandlerMapping>) field.get(bean);
          } catch (IllegalArgumentException | IllegalAccessException e) {
            throw new IllegalStateException(e);
          }
        }
      };
    }

  4. 配置application.yml

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    spring:
      mvc:
        pathmatch:
          matching-strategy: ANT_PATH_MATCHER
    springfox:
      documentation:
        swagger:
          v2:
            path: /api-docs
            use-model-v3: true     
    knife4j:
      # 开启knife4j的增强模式
      enable: true
      # 开启登录认证
      basic:
        enable: true
        username: admin
        password: 123456
    • springfox的配置可能没什么用，可以试试删除

  5. 最后通过localhost:8080/doc.html#/访问

扩展知识 | 网页抓取知识流程

easyExcel：java处理excel表格的库

看上了网页内容，怎么抓取？

  1. 分析原网站是怎么获取信息的？是哪个接口？

功能开发 | 修改用户信息

用户中心项目实现的用户信息修改是供管理员使用的：

  1. 只有管理员能够修改
  2. 管理员之间不能相互修改

这里我们实现普通用户修改自己的信息。

目前只有一个 UserController ，包含了所有的后端接口。现在进行一点小重构：

  • AdminController：管理员可以调用的接口，所有接口内部都要进行权限鉴定（该后端都在 controller 进行鉴权）。
  • UserController：所有用户都能调用的接口，例如登录。不需要鉴权。

功能开发 | 分布式登录

将用户中心的单机登录改为分布式登录。

核心思想：共享存储，所有后端服务器从一台共享服务器上读写 session

Redis 是一个快速读写的 K-V 式存储系统，在共享服务器上用 Redis 存储 session，能够满足我们的需求。

实现：

  1. 选择一台服务器，安装 Redis 服务，作为数据共享服务器，即下面的 Redis 服务器。

    开发时选择本机作为 Redis 服务器即可。

    • QuickRedis ： 管理 Redis 的工具，类似于 Navicat

  2. 在项目中引入 Redis：

    1. 引入 Spring Data Redis 依赖：spring-boot-starter-data-redis

      版本要与Springboot的版本保持一致

    2. application.yml添加 Redis 服务器配置：

      1
      2
      3
      4
      5
      6
      redis:
        # Redis 服务器的主机地址，开发时可以将本机作为 Redis 服务器
        host: localhost
        # Redis 服务器的端口
        port: 6379
        database: 0

    3. 引入 Spring Session Redis 依赖：spring-session-data-redis

      版本要与Springboot的版本保持一致

      这个依赖配合下面的配置，会自动实现从 Redis 中读写session

    4. application.yml添加配置：

      1
      2
      3
      session:
        # 默认为 none 表示存在单台服务器中
        store-type: redis

  3. 完成，不用修改任何一行登录逻辑。

功能开发 | 批量导入 | 并发编程

我们需要向数据库中插入大量用户信息（例如10w个用户）来模拟应用场景。

CompletableFuture是 Java 8 引入的一个非常强大的工具类，它提供了异步编程的能力。

基本概念：

  1. 异步执行，CompleTableFuture 允许创建并发任务执行，而不阻塞主线程。

  2. 组合任务，可以创建多个并发任务，并将他们分组执行。

  3. 默认使用 Java8 提供的 ForkJoinPool 线程池，其线程池的大小是确定的，由CPU的核心决定。

    如果 ForkJoinPool 不满足需求，可以使用自定义的线程池。

自定义线程池：

ThreadPoolExecutor是 Java 中非常强大的线程池实现，提供灵活的线程池配置。

ThreadPoolExecutor 构造器可传入的参数：

  • int corePoolSize, // 核心池大小
  • int maximumPoolSize, // 最大池大小
  • long keepAliveTime, // 线程空闲时的最大存活时间
  • TimeUnit unit, // 时间单位
  • BlockingQueue<> workQueue, // 任务队列
  • ThreadFactory threadFactory, // 创建新线程的工厂
  • RejectedExecutionHandler handler // 拒绝策略
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
void testInsertUser(){
  // 自定义线程池
  ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(60, 1000, 5, TimeUnit.MINUTES, new ArrayBlockingQueue<>(10000));
  StopWatch stopWatch=new StopWatch();
  stopWatch.start();
  final int INSERT_NUM=100000;
  int batch_size=10000;
  int j=0;
  List<CompletableFuture<Void>> futureList=new ArrayList<>();
  for (int i = 0; i < INSERT_NUM/batch_size; i++) {
    List<User> userList = new ArrayList<>();
    while(true){
      j++;
      User user=new User();
      user.setUserAccount("FakeUser");
      user.setNickname("假用户");
      user.setUserPassword("123456");
      user.setEmail("123456@mail.com");
      user.setPhone("123456");
      user.setGender(new Random().nextInt(2));
      user.setTags("[]");
      userList.add(user);
      if(j%10000==0){
        break;
      }
    }
    CompletableFuture<Void> completableFuture=CompletableFuture.runAsync(()->{
      System.out.println("thread-name:"+Thread.currentThread().getName());
      userService.saveBatch(userList,batch_size);
    },threadPoolExecutor);
    futureList.add(completableFuture);
  }
  CompletableFuture.allOf(futureList.toArray(new CompletableFuture[]{})).join();
  stopWatch.stop();
  System.out.println("耗时："+stopWatch.getTotalTimeMillis());
}

并发编程要注意：

  1. 执行的任务是先后无所谓的。
  2. 不要使用不支持多线程的集合，例如 List

功能开发 | 推荐用户 | 分页查询

在首页，展示与用户相似度高的用户。

查询的用户数量多且不用一次性返回给前端，所以使用分页查询：

  1. MybatisPlusConfig配置类，配置分页插件。参考 Mybatis-plus 文档。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    @Configuration
    @MapperScan("com.michael.usercenter.mapper")
    public class MybatisPlusConfig {
        @Bean
        public MybatisPlusInterceptor mybatisPlusInterceptor() {
            MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
            interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); 
            return interceptor;
        }
    }

  2. 分页查询：userService.page()

    1
    Page<User> userList=userService.page(new Page<>(pageNum，pageSize),queryWrapper);
    • pageNum：当前页目
    • pageSize：页面大小
    • 推荐用户的算法暂时是没有的，先按顺序返回用户，打通逻辑先。

下面要介绍 Redis，用来提高推荐用户接口的性能。

Redis 入门

Redis：基于内存的快速读写的 K-V 式存储系统。

  1. 安装 Redis，引入 Spring Data Redis 依赖。
  2. RedisTemplate：Spring Data Redis的核心类，封装了 Redis 操作的基本功能。

Redis的数据结构与方法：

  • String 字符串类型：name:“Michael”

  • List 列表：names:[“Michael”,”zmx”]

  • Set 集合：names:[“Michael”,”zmx”]（值不能重复）

  • Hash 哈希：nameAge:{“Michael”:1,”zmx”:2}

  • Zset 集合：names:{“Michael” - 10,”zmx” - 12} （给某个值关联一个数字）

RedisTemplate 为每种数据结构，都提供了相应的操作方法。以字符串类型为例，redisTemplate.opsForValue()的返回值是一个字符串类型的操作类ValueOperations，提供了增删改查等方法。

RedisTemplate 在存储数据时会将数据先序列化：

RedisTemplate 默认使用 JdkSerializationRedisSerializer作为序列化器，但是大多数情况下，使用它是会有乱码问题的：

  • 这个默认选择是出于灵活性的考虑。上面提到，Redis 有五种数据结构，每种数据结构的序列化是有细节差异的。JdkSerializationRedisSerializer是一个通用的序列化器，适用于多种类型的数据，并且能够支持任意 Java 对象。而代价是乱码问题。
  • 我们确实需要存储不同数据结构的Value，但是我们的Key一般都是字符串类型的。

**因此，我们需要根据实际存储的数据类型，自定义 RedisTemplate，单独为Key配置字符串序列化器。 **

RedisTemplate配置类：

1
2
3
4
5
6
7
8
9
10
@Configuration
public class RedisTemplateConfig {
    @Bean
    public RedisTemplate<String,Object> redisTemplate(RedisConnectionFactory redisConnectionFactory){
        RedisTemplate<String,Object> redisTemplate=new RedisTemplate<>();
        redisTemplate.setConnectionFactory(redisConnectionFactory);
        redisTemplate.setKeySerializer(RedisSerializer.string());
        return redisTemplate;
    }
}

当然，乱码问题不影响数据的正确性，从代码中取出数据时的反序列化也会把乱码消除。乱码只是影响我们从 Redis 工具如 QuickRedis 查阅数据。

功能开发 | 数据缓存 | 定时任务

前面的分布式登录就已经用到了Redis，进行了引入依赖以及配置。但存储的数据是session，而我们通过引入 Spring Session Redis 依赖就自动实现了功能。

现在就用代码真正操作 Redis。

场景：

还是推荐用户场景。这个功能使用的频次很高，响应时间要求很高，对数据时效性的要求不算高。

如果能将推荐用户的数据保存在缓存中，可以有效提高查询的效率，并且通过定时更新（推荐用户可以一天一更新，根据需求而定）来保证时效性。

使用 Redis 进行缓存：

  1. 先查询 Redis 中是否有缓存数据。
  2. 如果没有，则从数据库中查询，并保存到 Redis 中
  3. 设置过期时间（很重要，别把Redis爆了）。

以上逻辑，显然对部分用户不友好（查询前缓存刚好失效，只能从数据库中查询，耗时长）。所以我们可以加入定时任务，定时更新缓存数据（这种方式也叫缓存预热）。

使用定时任务进行缓存的更新：

定时任务有多种实现方式：

  1. Spring Scheduler（Springboot默认整合了）
  2. Quartz（独立的定时任务框架）
  3. XXL-job（开源项目，有学习价值，分布式的任务调度平台，界面+SDK）

这里就使用第一种：

  1. Springboot 的启动类上加上@EnableScheduling开启定时任务功能。
  2. 定时任务方法上加上@Schduled，注解有多个参数，用来配置任务的时间、次数等等。

功能开发 | 定时任务控制方案 | 分布式锁

在上一节，使用了定时任务来实现了缓存更新。但这又导致了新的问题：在多台服务器部署时，每个服务器都会执行一次定时任务更新缓存，而这是多余的，因为 Redis 的数据是共享的。

如何实现同一时间只有一台服务器执行定时任务？

  1. 方案一：将定时任务从项目分离出来，专门在一台服务器上运行（成本太高）。

  2. 方案二：在代码中通过 IP 限制任务执行，只有一个 IP 下的服务器可以执行更新操作，其他的服务器直接返回（成本低）。

    • 缺点：把代码写死了，如果要修改 IP ，还得改代码重新上线；而且如果这台服务器崩了那任务直接不执行了）
    • 解决方法：将这个 IP 存在数据库或者配置中心，方便修改
      1. 数据库
      2. Redis
      3. Nacos，Apollo，Spring Cloud Config
    • 无论如何还是人工配置，人为修改

注意：这两种方案只是不适合解决当前的问题，但体现出的思路是可以应用在其他场景下的，这也是将他们写出来的原因。

第三种解决方案：分布式锁

关键概念：锁是共享存储的，服务器抢锁，抢到后加上自己的标识，别人不能再用。用完后释放锁。

  • 选择共享服务器作为锁共享存储的地方。
  • 锁的操作要有同步异步机制。
  • 请求服务器要手动释放锁，如果请求服务器挂了，也要保证共享服务器能根据设置的过期时间，到期自动释放锁。

以上要求我们使用 Redis 的setIfAbsent()和delete()就可以完成。

Boolean setIfAbsent(K key, V value, long timeout, TimeUnit unit);

  • 底层是是 Redis 的setnx命令，如果key不存在则返回1，若存在则返回0，保证Redis内是单线程操作；
  • key是锁的名称，value可以用来标识请求线程。

Redis的分布式锁实现示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
String lock = "lock_key";
String value = UUID;
ValueOperation<String,String> ops = redistemplate.opsForValues();
// 获取锁，并设置自动过期时间
boolean lock=ops.setIfAbsent(lock,value,5,TimeUnit.MINUTES);

try{
  if(lock){
    执行任务
  }
}finally{
  //释放锁
  redisTemplate.delete(lock);
}

但是这样还不能满足复杂场景

试想，如果过期时间设置为10min，但是我们的任务执行了10min还没执行完，那么是不是应该有一个自动延期机制？如果不自动延期，那么锁被释放了，但是任务还在执行，另一个线程拿到锁又开始执行任务，这就破坏锁的机制了。

我们自己实现自动延期有点复杂而且没必要，因为Redisson就具备这样的功能。

功能开发 | 引入Redisson

Redisson 是一个基于 Redis 的 Java 客户端，提供了大量的分布式数据集来简化对 Redis 的操作和使用，可以让开发者像使用本机集合一样使用 Redis，完全感知不到 Redis 的存在。

  1. 引入依赖，有2种引入方式：

    • 引入 redisson-springboot-starter依赖，即 redisson 与 springboot 的整合版，能简化很多操作。（不推荐，redisson 更新快，引入整合包容易造成冲突）
    • 直接引入 redisson 的依赖，自定义客户端。（推荐）

  2. RedissonConfig配置类：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    @Bean
    public RedissonClient redissonClient(){
      // 创建配置
      Config config=new Config();
      String redissonAddress="redis://127.0.0.1:7181";
      config.useSingleServer().setAddress(redissonAddress).setDatabase(3);
      
      // 创建 redisson 实例
      RedissonClient redisson=Redisson.create(config);
      return redisson;
    }

  3. Redisson提供的分布式数据集：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    public testRedisson(){
      RedissonClient redisson=new RedissonClient();
      
      // list，本地集合
      List<String> list=new ArrayList<>();
      list.add("michael");
      list.get(0);
      list.remove(0);
      
      // RList，数据存在 Redis
      RList<String> rList=redisson.getList("aRedissonList");
      rList.add("michael");
      rList.get(0);
      rList.remove(0);
    }

    可以看到，RList 提供的接口与 List 完全一致，可以让开发者像使用本机集合一样使用 Redis。这是因为 RList 的实现是完全继承了 List 接口。 RMap、RSet 同样如此。

  4. Redisson 还可以实现分布式锁，下面开始实现。

功能开发 | 缓存更新 | Redisson分布式锁实现

使用 Redisson + 定时任务 实现实现分布式锁，执行缓存更新任务。

核心逻辑的伪代码：

1
2
3
4
5
6
7
getLock
if(tryLock){
  执行任务
  if(isHeldByCurrentThread){
    unlock
  }
}
  • tryLock 是原子操作
  • isHeldByCurrentThread与unlock一起也是原子操作，这在底层是通过 lua 脚本实现的。

实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
@Component
@Slf4j
public class DoRecommendCache {
  @Resource
  private RedissonClient redissonClient;
  @Resource
  private RedisTemplate<String,Object> redisTemplate;
  @Resource
  private UserService userService;
  private List<Long> mainUserList = Arrays.asList(new Long[]{1L});

  @Scheduled(cron = "0 1 21 11 * *")
  public void doRecommendCache() {
    RLock lock = redissonClient.getLock("michael:usercenter:recommend:lock");
    try {
      if (lock.tryLock(0, 30, TimeUnit.MINUTES)) {
        ValueOperations<String, Object> operations = redisTemplate.opsForValue();
        for (Long mainUserId : mainUserList) {
          QueryWrapper<User> queryWrapper = new QueryWrapper<>();
          Page<User> page = userService.page(new Page<>(1, 8), queryWrapper);
          // 写缓存，过期时间为 10 min
          String key = String.format("michael:usercenter:recommend:%s", mainUserId);
          operations.set(key, page, 10, TimeUnit.MINUTES);
        }
      }
    } catch (Exception e) {
      log.error(e.getMessage());
    } finally {
      if (lock.isHeldByCurrentThread()) {
        lock.unlock();
      }
    }

  }
}

  • cron 表达式，安排任务的执行时间。

  • getLock(key)：Redisson 会根据传入的锁名称构造一个 Redis 键。调用 SETNX 命令，检查该键是否存在。如果该键不存在，SETNX 会创建这个键并为其值设置为一个唯一标识符（通常是当前客户端的 UUID），表示锁已经被当前客户端占用。

    如果键已存在，表示锁已被其他客户端持有，当前客户端无法获取锁。

  • tryLock(waitTime,leaseTime,TimeUnit)：尝试加锁，等待指定的时间。

    • waitTime：等待时间，设置为0，抢不到锁就溜。
    • leaseTime：锁的过期时间。

  • isHeldByCurrentThread()：是否是自己加的锁。

  • lock.unlock()：一定要写在 finally 中，保证即使抛出异常，锁也会被释放。

为什么要划分 getLock() 与 tryLock() ？

在上面的代码中，我们先执行了getLock()得到lock，再执行了lock.tryLock()，这不禁让人疑惑——为什么要这样划分？难道不能将tryLock 的功能合并到 getLock 中吗？

在回答之前，我们还要介绍lock的另一个方法：lock.lock()

lock()与tryLock() 的区别：

  • 前者阻塞加锁，如果没有得到锁，就会阻塞进程，直到获取到锁
  • 后者尝试加锁，如果在waitTime时间内没有得到锁，就返回；如果得到锁，就进一步执行。

基于这点，就理解了设计getLock()和trylock()是出于程序灵活性的考虑：

  1. getLock() 返回一个锁对象，如果不存在就创建锁
  2. 如果是一定要执行的任务，就执行lock()
  3. 如果不是，就执行tryLock()，避免进程一直被阻塞。

这样的设计可以处理更多应用场景。

Redisson 锁的自动续期：Watch Dog 看门狗机制：

在tryLock()中，如果执行任务的耗时大于锁的过期时间，就导致锁提前释放，其他任务也可以执行，锁的机制就被破坏了。

Redisson 提供了一种 看门狗 机制来解决这种情况：

  1. 将leaseTime设置为 -1，看门狗机制就会生效。
  2. 内部自动将leaseTime设置为30s，每隔10s，如果任务没有完成，则续到30s。
  3. 如果监听到任务线程宕机（开发时debug也会被认为是宕机！！），则不会再续时间，锁被释放。

功能开发 | 组队功能 | 需求分析

需求分析：

用户能创建队伍，队伍名称，队长，描述，人数限制，时间限制

规定创建时队长只能是自己。

队长可以修改队伍信息

用户可以根据队伍信息搜索

队伍的状态：公开、仅自己可见、加密（字段要加一个密码）

用户加入队伍（需要申请？同意？）

邀请别人加入队伍

用户可以退出队伍

队长可以解散队伍

用户同时加入的队伍数量有上限

队伍人满之后要有消息通知

数据库设计

team表

  1. 队伍ID id bigint

  2. 队伍名 teamName varchar

  3. 队伍描述 description varchar

  4. 队长id userId bigint

  5. 最大人数 maxNum int

  6. 招募期限 expireTime

  7. 队伍状态 teamStatus 0-公开 1-私密 2-加密

  8. 入队密码 enterPassword varchar

  9. createTime

  10. updateTime

  11. isDelete

user 与 team 的关系如何维护？

  • 方案一：新建 user-team 的关系表
  • 方案二：在 user 表中维护已加入队伍字段，在 team 表中维护已有队员字段

如何选择需要考虑很多因素，这里不深究，选择更教科书的方案一。

user_team表

  1. id bigint

  2. 队伍ID teamId bigint

  3. 用户ID userId bigint

  4. 加入时间 joinTime datetime

  5. createTime

  6. updateTime

  7. isDelete

功能开发 | 创建队伍 | 接口设计

接口的逻辑有一定的复杂度，开发时先写好接口设计，检查是否有错误，再写代码会很快。

接口设计

接收的参数：名称，描述，最大人数，招募期限，队长，队伍状态，密码

封装一个请求参数接收类：TeamCreateRequest。

接口逻辑：

  1. 检验登录态。

  2. 参数判空：名称，描述，最大人数，队长，队伍状态。（招募期限和密码可以为空）

  3. 校验参数：

    1. 名称长度。

    2. 描述长度。

    3. 校验最大人数

    4. 校验招募期限：

      • 为空则视为永久可加入。

      • 不为空则要大于当前时间

      • 前端要传这样的数据：”2025-02-14T01:40:54.689Z”

      • 如果只传”2025-02-14”会有8小时问题，是前端的问题。

    5. 校验队伍状态，如果加密，则密码不能为空

    6. 队长ID是否存在（创建时队长只能是当前登录用户）

  4. 查询用户已加入的队伍数，最多同时加入5支队伍。

  5. 开启事务：两个表要么都插入成功要么都失败。

    1. 在 service 层的方法上加上注解：@Transactional
    2. 插入到用户表
    3. 插入信息关系表

功能开发 | 创建接口 | @Transactional

实际上，每一条数据库执行的语句都要经过事务管理。默认情况下，数据源底层为每一次SQL语句都自动进行 commit 操作（包括查询操作，即使它不修改数据），调用teamMapper的方法，我们不用写任何写有关 commit 的代码，就已经被自动提交。

所以，如果我们想要参与事务管理，实际上就是要把这个底层的自动提交机制给关掉，在代码中显式的 commit。

@Transactional 做了什么：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
关闭数据源的自动提交
try{
  执行被注解的方法
}catch(RuntimeException及其子类、ERROR){
  处理
  needRunBack=true
}finally{
  重置数据库的配置信息，包括把自动提交重新开启
}

if(needRunBack){
  回滚
  return
}
commit

关于这个注解的原理分析，这篇文章中介绍的很好

功能开发 | 创建队伍 | 并发处理

模拟这样的并发场景：用户已加入四个队伍（最多五个），但是创建第五个队伍时猛点100下创建，导致100个请求在检查用户已创建队伍数量时都是4个，所以这100个队伍都被允许创建了。

加锁 @Synchronized

在 service 层 createTime() 方法上加上 @Synchronized 注解，实现该方法在并发多线程下的原子性。

（额，后来发现 @Transactional 和 @Synchronized一起使用会出大问题，这里不删除这段是为了留个犯错记录）

单元测试 | 创建队伍

  1. 测试创建接口逻辑
  2. 测试并发多线程下的问题。

功能开发 | 查询队伍 | 接口设计

接口返回的信息包括：队伍信息以及队伍中所有成员的信息。

接口设计：

封装一个 DTO 类用来接收参数：TeamQuery

接口逻辑：

  1. 参数校验：

    1. 可选参数：参数可以为空，代表不作为查询条件。

      1
      2
      3
      4
      5
      6
      private Long teamId;
      private String teamName;
      private String description;
      private Long userId;
      private int maxNum;
      private int teamStatus;

    2. 已过招募期限的队伍不展示

    3. 私密的队伍只有管理员才能查看。

  2. 根据参数查询出队伍信息。

  3. 根据队伍查询出队友成员信息。（涉及 TeamUser 与 User 的多表联查）

  4. 将队伍信息与成员信息封装成一个 VO 返回

  5. 上述使用分页查询。

功能开发 | 多表联查 | Mybatis-Plus-Join

Mybatis-Plus-Join 是一个 Mybatis-Plus 的增强工具，主要增强多表联查方面的功能，能够以类似 Mybatis-plus 中 QueryWrapper 的方式来进行联表查询（mybatis-plus本身是没有的），而不用写 SQL 语句。

  1. 引入 Mybatis-Plus-Join 依赖
  2. 如果 TeamUser 与 User 的要实现多表联查，只需要将二者的 mapper 改为继承 MPJBaseMapper。
  3. 这样就可以使用多表联查的 API，具体用法参考官方文档。

使用 Mybatis-Plus-Join 实现查询队伍接口部分代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 2. 根据参数查询出队伍信息。
Page<Team> teams=this.page(new Page<>(teamQuery.getPageNum(),teamQuery.getPageSize()),queryWrapper);
if(teams!=null){
  // 3. 根据队伍查询出队友成员信息。（涉及 TeamUser 与 User 的多表联查）
  // 4. 将队伍信息与成员信息封装成一个 VO 返回
  // 5. 上述使用分页查询。
  List<TeamUserVO> teamUsers=new ArrayList<>();
  for(Team team:teams.getRecords()){
    MPJLambdaWrapper<TeamUser> mpjQueryWrapper = new MPJLambdaWrapper<TeamUser>()
      .selectAll(User.class)
      .leftJoin(User.class,User::getId,TeamUser::getUserId)
      .eq(TeamUser::getTeamId,team.getId());
    List<UserVO> userVOS = teamUserMapper.selectJoinList(UserVO.class,mpjQueryWrapper);
    TeamUserVO teamUserVO=new TeamUserVO();
    teamUserVO.setTeamId(team.getId());
    BeanUtils.copyProperties(team,teamUserVO);
    teamUserVO.setUserList(userVOS);
    teamUsers.add(teamUserVO);
  }
  Page<TeamUserVO> res=new Page<>(teamQuery.getPageNum(),teamQuery.getPageSize());
  res.setRecords(teamUsers);
  return res;
}

单元测试 | 查询接口

测试查询接口逻辑

功能开发 | 校验参数 | AOP+自定义注解

开发进行到这里，发现有很多重复的参数校验代码，例如几乎所有接口都要校验参数是否为空或者空字符串。

最简单的参数校验的方法，就是在 controller 方法中进行参数校验。但是这样做在 controller 方法中会有大量重复、没有太大意义的代码。

为了保证 controller 中的代码有更好的可读性，我们可以借助 AOP 的思想来进行统一的参数校验。

实现思路：

  1. 自定义注解@Verify，用来标注需要进行校验的参数。

  2. 自定义切面类aspect，在里面配置切入类的切入点，以及切入后执行的操作，我们对参数的校验逻辑就是写在这里。

    举个例子，在这个场景下，切入点就是 controller 的方法，切入后执行的操作就是参数校验。

  3. 对于不满足的参数直接抛出自定义异常，交由全局异常处理来处理并返回友好的提示信息。

因为这个功能具有泛用性，所以可以把实现代码独立写在一个 paramValidator 包中，日后完善还可以打包成依赖。

paramValidator 目录结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
├─paramValidator
│  ├─annotation
│  │      Verify.class
│  │
│  ├─aspect
│  │      EntityValidatorAspect.class
│  │
│  ├─enums
│  │      RegexOption.class
│  │
│  ├─exception
│  │      ParamAssert.class
│  │      ParamExceptionHandler.class
│  │      ParamException.class
│  │
│  └─result
│          Result.class
  • Verify：注解类，包含name required notNull maxLength minLength regular等属性
  • RegexOption：正则表达式的枚举类，用于注解的regular属性
  • EntityValidatorAspect：切面类，进行对注解属性的逻辑校验。
  • ParamAssert：断言工具类，在代码的执行过程中，经常需要在满足条件时抛出异常，此时需要加入抛异常、返回状态码、错误信息、记录日志等操作，此操作是大量重复的操作，所以借助 Juni t中 Assert 的思想，创建了的断言工具类。
  • ParamExceptionHandler：统一处理抛出的异常，进行打印日志、生成通用返回类等。
  • ParamException：自定义的参数异常类
  • Result：自定义的通用返回类

功能开发 | 修改队伍 | 接口设计

接口设计：

封装请求参数接收类：TeamUpdateRequest

maxNum 不允许修改。

接口逻辑：

  1. 检查登录态
  2. 校验参数：
    1. 只有队长或管理能修改
    2. 新队长要存在（如果有）
    3. 新队长必须已经在队伍中
    4. 招募期限不能先于当前时间
    5. 最多人数不允许修改
  3. 更新队伍信息

功能开发 | 修改队伍 | 并发处理

该方法似乎只会有一种并发情况：多个管理员同时修改信息，而且这样的情况也很少见，并发量不会很大，应该可以不处理。

出于学习目的，还是实现一下乐观锁。

功能开发 | 修改队伍 | 乐观锁

概念：乐观锁总是假设最好的情况，即在读取数据和提交更新之间，其他事务不会修改数据。因此，它不会在读取数据时加锁，而是在更新数据时检查是否有其他事务已经修改了数据。

如何检查？

  1. 给数据的表和实体类均新增一个字段version
  2. 对数据进行修改时：
    1. 先进行一次查询，得到此时数据的version
    2. 将这个version值赋给新的数据
    3. 将新数据插入时，检查新数据的version与表中数据的version是否相等：
      1. 如果相等，则说明期间没有其他事务修改数据，继续更新。
      2. 反之则有其他事务已经修改数据，此次更新终止。

使用Mybatis-plus提供的乐观锁插件

插件能自动完成上述步骤中的第2.3步 ，其他的步骤还需要自己完成。参考官方的乐观锁插件文档。

功能开发 | 加入队伍 | 接口设计

接口设计：

封装请求参数接收类：TeamJoinRequest

接口逻辑：

  1. 检查登录态
  2. 校验参数：
    1. 加入的队伍存在
    2. 加入的队伍是非私密的
    3. 如果是加密的队伍，则要校验密码
    4. 加入的队伍是未满的
    5. 加入的队伍是非过期的
    6. 最多只能同时加入上限个队伍
    7. 不能重复加入已加入的队伍
  3. 更新数据

功能开发 | 加入队伍 | 并发处理

模拟这样的并发场景：用户在加入队伍时，猛点100下加入，导致100个请求并发，校验全部通过，导致数据库中 TeamUser 表新增100条重复数据。

解决方案：

  • 方案一：用 @Synchronized 注解。我们在创建队伍时就是这样做的。

    但是这样做在分布式场景下不能生效：分布式场景下，存在多个用户同时申请加入队伍，而 @Synchronized 只限制单机的并发。

    （创建队伍不存在这样的场景，所以可以用 @Synchronized 应对并发）

  • 方案二：分布式锁。因为涉及新增数据，乐观锁不适用，所以采用悲观锁思路。

功能开发 | 加入队伍 | 数据库分布式锁方案

实现分布式锁要考虑的细节：

  1. 抢锁是一个原子操作。

  2. 锁加过期时间。

  3. 如果执行时间过长，锁过期了？：

    1. A锁过期，B抢到锁，A、B同时执行。
    2. A还在执行，但锁过期了，B上锁；A执行完成，以为这个锁还是自己的，所以释放掉了，C抢到锁，引起连锁反应

    要用锁延期来解决这个问题。

  4. 还要给锁加上自己的标识，只能释放自己锁。

  5. 从判断是否是自己锁到释放自己锁的这一段操作也要是原子操作。

实现：基于数据库的分布式锁方案：

  1. 锁的表结构

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    CREATE TABLE `resource_lock`
    (
      `keyResource` varchar(45) COLLATE utf8_bin NOT NULL DEFAULT '资源主键',
      `lockStatus`       char(1) COLLATE utf8_bin     NOT NULL DEFAULT '' COMMENT 'S-成功,F-失败,P-过期',
      `lockFlag`    int(10) unsigned             NOT NULL DEFAULT '0' COMMENT '1是已经锁 0是未锁',
      `beginTime`   datetime                              DEFAULT NULL COMMENT '开始时间',
      `endTime`     datetime                              DEFAULT NULL COMMENT '结束时间',
      `UUID`    char(36) COLLATE utf8_bin NOT NULL DEFAULT '抢到锁的节点的UUID',
      `time`         int(10) unsigned             NOT NULL DEFAULT '60' COMMENT '方法生命周期内只允许一个结点获取一次锁，单位：分钟',
      PRIMARY KEY (`keyResource`) USING BTREE
    ) ENGINE = InnoDB
      DEFAULT CHARSET = utf8
      COLLATE = utf8_bin

  2. ResourceMapper.xml 自定义 SQL 语句 :

    使用select for ... update：查询数据的同时为数据加写锁，直到事务提交时释放。

    注意，在Springboot+Mybatis中，数据源底层为每一次数据库操作（包括查询操作，即使它不修改数据）都自动执行了事务提交操作，所以在下面的 service层 要使用 @Transactional 关闭自动提交，否则一加上锁就会被立刻释放。

    • **getLock(Param:keyResource)**：

      1
      2
      3
      4
      5
      <select id="getLock" parameterType="java.lang.String" resultType="com.michael.usercenter.model.domain.ResourceLock">
          select * from 'resource_lock'
          where keyResource = #{keyResource,jdbcType=VARCHAR}
              for update
      </select>

  3. ResourceLockService 接口设计：（仿照Redisson，设计 getLock 和 tryLock 的原因在上面 Redisson分布式锁小节有解释）

    • **ResourceLock: getLock(String keyResource)**：

      1. @Transactional：主要的作用是关闭自动提交。

        如果不关闭自动提交，在下面调用mapper.getLock()中，select for update本身也会触发事务提交，导致锁立刻失效。

      2. 调用mapper.getLock()，返回数据库中资源的锁lock

      3. 如果lock为空，则创建lock:

        1. keyResource设为当前资源key
        2. status设为 S
        3. lockFlag设为1
        4. beginTime设为当前时间
        5. time数据库默认为60min，表示锁的生效时长
        6. endTime=beginTime+time
        7. 生成UUID并填入
        8. 向数据库中更新lock

      4. 返回lock

    • boolean: tryLock(String keyResource, int waitTime, int leaseTime):

      1. @Transactional
      2. 开始waitTime计时：
        1. 调用mapper.getLock()，获取lock
        2. 检查lock的字段：
          1. 如果lockFlag为1且status为P，表示正在被占用，如果计时还未结束，则重复上一步
          2. 如果lockFlag为1且status为F，表示正在被占用但是已经过期，如果计时还未结束，则重复上一步（TODO 锁的过期管理机制）
          3. 如果lockFlag为0且status为S，表示锁空闲，进行下一步
        3. 如果计时结束，则直接返回false
      3. 如果锁空闲：
        1. beginTime设为当前时间
        2. time设为leaseTime的值
        3. endTime=beginTime+time
        4. lockFlag设为1
        5. status设为P
        6. 生成UUID并填入
        7. 向数据库中更新lock
        8. 返回true

    • boolean: lock(String keyResource, int leaseTime):

      TODO

    • void: unlock(String keyResource, String UUID):

      unlock() 相当于 Redisson 的 isHeldByCurrentThread() + unlock()，但是 Redisson 用 lua 脚本保证了这一组合的原子性。这里不打算引入 lua 脚本，所以整合为一个方法，配合行级锁来保证原子性。

      1. @Transactional
      2. 调用mapper.getLock()，得到lock
      3. 将lock.UUID与 UUID 比较。
      4. 如果相等：
        1. lockFlag设为0
        2. status设为S
        3. 向数据库更新lock
      5. 如果不等，则直接返回

功能开发 | 偷懒

组队相关的功能还应该实现的有：

  1. 用户退出队伍
  2. 队长解散队伍

但是这两个功能的实现都是写业务逻辑，没有涉及新的知识点，所以就偷懒不实现了，目前为止写的业务逻辑已经够多了。

再别说。

功能开发 | 随机匹配算法

算法文章

前后端开发

前后端联调 | 引入 Axios

使用 Axios 发送网络请求。

在用户中心项目中，前端使用了 Ant Design Pro 框架，Ant Design Pro自身集成了 Axios 库。

而本项目前端是使用 Vite 生成的 Vue 脚手架，没有集成 Axios。

  1. 引入 Axios 库：npm install Axios

  2. 创建src/plugins/myAxios.ts，为请求设置公共的baseURL：

    1
    2
    3
    4
    5
    import axios from 'axios';
    const myAxios = axios.create({
        baseURL: 'http://localhost:8080/api',
    })
    export default myAxios;

    这样，在项目中就使用myAxios来发送请求。

  3. 前面有提到配置 Axios 的跨域问题。

  4. 创建 src/services/api.ts，集中封装 API

  5. 在api.ts中编写接口API

  6. 调用接口进行测试

总结

  1. 还未查询了解的概念：

    1. Redis 的分布式，多台Redis服务器，Redis 集群 红锁
    2. 缓存雪崩？缓存穿透？Redis连接池？

  2. bug：

    1. 修改了包路径后提示找不到类，java.lang.ClassNotFoundException，看日志发现最外层是 redis 的包抛出的错误。

      在这篇帖子找到了同样的问题并解决。原因大概是：由于Redis缓存路径依赖于对象的原始类名，即使类名已更改，仍试图在旧路径下寻找。解决方法是清理Redis的数据并重新调用接口。

  3. 学到的 Java 知识点

    • Optional.ofNullable(teamQuery.getTeamStatus()).orElse(-1);

    • BeanUtils.copyProperties();

    • GSON 类库：提供处理 JSON 格式的数据的API，

      例如 把 JSON 格式的数组转成 List<String> ：

      List<String> tempTagNameList=gson.fromJson(tagStr,new TypeToken<List<String>>(){}.getType());

    • 并发编程 CompleTableFuture，如果默认的线程池满足不了需要，还可以自定义线程池。

    • Java8 StreamAPI

  4. 学到的后端知识点：

    1. 养成写接口设计的习惯，先设计，再开发。
    2. 整合接口文档 Knife4j (是Swagger的增强版)，能够自动生成文档，还提供了简洁好用的调试功能，GOOD！
    3. 引入 Redis，快速将单机登录改为分布式登录
    4. 使用 Redis，对经常使用的数据进行缓存。
    5. 理解定时任务的概念，使用 定时任务+redis 实现对数据的缓存预热
    6. 引入 Redisson，基于 Redisson 实现分布式锁对分布式下的定时任务的进行管理。
    7. 通过 AOP+自定义注解 方式，对重复的参数校验代码进行优化。
    8. 使用 Mybatis-Plus 的分页插件
    9. 使用 Mybatis-Plus-Join 插件优化多表联查的操作。
    10. 线程锁的关键字 synchronized 以及注解 @Synchronized 的区别。
    11. 事务管理的注解@Transactional，实际上进行了：关闭自动提交、处理异常并回滚、重置自动提交、自动提交等一系列操作。
    12. @Transactional和 synchronized 放在一起使用会出大问题，这篇文章讲的很好。
    13. 理解 Mybatis-plus 的乐观锁思想，使用乐观锁处理并发的数据修改操作，保证数据正确。
    14. 设计了一套基于数据库的分布式锁方案。

  5. 学到的前端知识点：

    1. Vite、Vue、Vant、Vue Router的使用
    2. 使用 Pinia 进行前端的状态管理（自己拓展的）。

展开全文 >>

用户中心项目-readme

[TOC]

用户中心项目-readme

这个文档用于梳理该项目的开发历程。

前端初始化

使用Ant Design Pro初始化前端项目

Ant Design Pro = React + Ant Design + Umi，具有强大的构建CRUB页面的能力，这正是我们项目所需要的。

安装Ant Design Pro，初始化前端项目。具体操作参考Ant Design Pro官方文档 => 开始使用

这项目使用的版本是V5

Ant Design Pro的页面

“页面”指的是：配置了路由，可以直接通过url链接访问到的模块。在项目中，页面文件后缀为.tsx，全部存放在src/pages目录下

后端初始化

初始化Springboot项目的三种方式：

  1. github上寻找相应现成的模板项目
  2. 在网站spring.io上根据需求勾选，会自动生成一套模版项目的压缩包
  3. 借助IDEA生成（推荐）

使用IDEA初始化项目结构

image-20250116205806565

一般的Springboot项目所需要勾选的基本依赖：

  1. 工具类：Lombok、Spring Boot DevTools、Spring Configuration Processor

  2. Web开发：Spring Web

  3. 数据库：（常用）MySQL Driver、Mybatis Framework

IDEA没有提供Mybatis-Plus的选项，而当前的项目基本流行使用Mybatis-plus，所以我们自己在pom文件中添加依赖，也很简单，直接搜索Mybatis-Plus的官方文档即可。

实用工具类库：（每个项目都可以引这些，方便写代码）

  • apache commons lang
  • com.google.code.gson

初始化数据库

IDEA同样集成了连接数据库的功能，自行探索即可~

image-20250116211044191

项目demo试运行

在初始化项目后，我们应该写一个简单的项目demo来测试我们目前工作的正确性。

  1. 配置application.yml文件：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    spring:
      application:
        name: user-center
      datasource:
        driver-class-name: com.mysql.cj.jdbc.Driver
        url: jdbc:mysql://localhost:3306/user-center
        username: root
        password: zmx004200412
    server:
      port: 8080

  2. 编写一个用户实体类User

    1
    2
    3
    4
    5
    6
    7
    @Data
    public class User {
        private Long id;
        private String name;
        private Integer age;
        private String email;
    }

  3. 编写一个User的Mapper类

    1
    2
    public interface UserMapper extends BaseMapper<User> {
    }

  4. 创建数据库，在Mybatis-Plus的官方文档中提供了一段创建User表并插入一些数据的SQL语句，直接CV即可。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    DROP TABLE IF EXISTS `user`;

    CREATE TABLE `user`
    (
        id BIGINT NOT NULL COMMENT '主键ID',
        name VARCHAR(30) NULL DEFAULT NULL COMMENT '姓名',
        age INT NULL DEFAULT NULL COMMENT '年龄',
        email VARCHAR(50) NULL DEFAULT NULL COMMENT '邮箱',
        PRIMARY KEY (id)
    );
    DELETE FROM `user`;

    INSERT INTO `user` (id, name, age, email) VALUES
    (1, 'Jone', 18, 'test1@baomidou.com'),
    (2, 'Jack', 20, 'test2@baomidou.com'),
    (3, 'Tom', 28, 'test3@baomidou.com'),
    (4, 'Sandy', 21, 'test4@baomidou.com'),
    (5, 'Billie', 24, 'test5@baomidou.com');

  5. 在Test类来编写测试方法查询User数据

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    @RunWith(SpringRunner.class)
    @SpringBootTest
    public class SampleTest {

        //@Resource与@Autowired都是实现自动注入的注解，在这里使用@Autowired也可以。
        //二者的区别是：前者按照名称匹配，后者按照类型匹配。因此，使用@Autowired时，要在mapper类中增加@Mapper注解。以让spring知道这是一个可以使用的bean
        @Resource
        private UserMapper userMapper;

        @Test
        public void testSelect() {
            System.out.println(("----- selectAll method test ------"));
            List<User> userList = userMapper.selectList(null);
            Assert.isTrue(5 == userList.size(), "");
            userList.forEach(System.out::println);
        }

    }

  6. 测试通过

    1
    2
    3
    4
    5
    6
    //输出
    User(id=1, name=Jone, age=18, email=test1@baomidou.com)
    User(id=2, name=Jack, age=20, email=test2@baomidou.com)
    User(id=3, name=Tom, age=28, email=test3@baomidou.com)
    User(id=4, name=Sandy, age=21, email=test4@baomidou.com)
    User(id=5, name=Billie, age=24, email=test5@baomidou.com)

数据库设计

User表

字段名 类型 解释
id bigint 用户ID
userAccount varchar 用户账号
nickname varchar 昵称
avatar varchar 头像url
userPassword varchar 登录密码
e-mail varchar 邮箱
phone varchar 电话
gender tinyint 性别(男0)
status tinyint 状态（默认正常0）
userRole int 用户状态（0-普通用户，1-管理员）
createTime datetime 创建时间，默认值设为current_timestamp()
updateTime datetime 更新时间，默认值设为current_timestamp()
isDelete tinyint 是否逻辑删除（默认否0）

createTime、updateTime、isDelete是每个表都要有的字段，与业务无关。

为updateTime字段添加触发器，修改数据时自动更新：

1
2
ALTER TABLE user
MODIFY COLUMN updateTime TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

Mybatis-plus

驼峰规则

Mybatis-plus 默认开启自动驼峰命名规则（camel case）映射，即从经典数据库列名 A_COLUMN（下划线命名） 到经典 Java 属性名 aColumn（驼峰命名） 的类似映射。

但我们数据库字段的设计就是选用了驼峰式，所以可以把机制关闭。

如果有需要则可以不设置。

1
2
3
mybatis-plus:
  configuration:
      map-underscore-to-camel-case: false

Mybatis-plus提供的逻辑删除功能：

  • 什么是逻辑删除？对数据进行删除操作时，将删除操作转为更新操作，更新操作为：将数据的逻辑删除字段置为有效，表示该条数据已被删除。

  • 使用方法：

    • 为每个表增加一个字段isDelete：{0,1}

    • 在application.yml配置：

      1
      2
      3
      4
      5
      6
      mybatis-plus:
        global-config:
          db-config:
            logic-delete-field: isDelete # 全局逻辑删除字段名
            logic-delete-value: 1 # 逻辑已删除值
            logic-not-delete-value: 0 # 逻辑未删除值

    • 在表对应的实体类中声明成员变量isDelete，加上@TableLogic注解，表示这是逻辑删除字段

后端开发

MybatisX代码生成器

在编写业务逻辑前，肯定要先写好domain（实体类）、对应的Mapper类（操作数据库的对象）、对应的Mapper.xml（定义了Mapper类与数据库的关联）、对应service类（包括常用的增删改查）以及serviceImpl类。

MybatisX插件可以根据数据库中表的结构，一键生成上述代码，提高工作效率。

使用方法：安装后，在IDEA数据库工具中，找到表并右键即可找到使用

image-20250201200937112

使用MybatisX生成代码后，也应该写一个单元测试来保证工作的正确性。

image-20250117222920932

单测代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
@SpringBootTest
class UserServiceTest {

    @Resource
    private UserService userService;

    @Test
    void testInsert(){
        User user =new User();
        user.setUserAccount("Michael");
        user.setNickname("neuro今天吃什么");
        user.setAvatar("A265575EABEA7DF9179ndex=7&itb=0");
        user.setUserPassword("123456");
        user.setEmail("123");
        user.setPhone("123");
        user.setGender(0);
        boolean result=userService.save(user);
        System.out.println(user.getId());
        Assert.assertEquals(true,result);

    }

}

generatorAllSetter

该插件可以一键生成对一个实体类所有字段的setter或getter的调用的代码，提高工作效率。

功能开发 | 注册逻辑

  1. 接收参数：账号、密码、校验码
  2. 校验用户的账号、密码、校验码是否符合格式，账号是否重复
  3. 对密码加密
  4. 向数据库中插入数据

MybatisX生成的Impl类是继承了框架自带的ServiceImpl类，所以有很多自带的实用方法：

  • save（）：插入数据，参数是表对应的实体类，例如向user表中插入数据就传入一个User对象

  • count（）：根据条件查询并返回数据库中符合条件的数据个数，参数是一个QueryWrapper<>对象，用来封装查询条件。

  • list（）：根据条件查询数据库中符合条件的数据，返回的是一个List集合

QueryWrapper具体是一个条件构造器。

1. QueryWrapper.eq（）：按条件精准查询
2. QueryWrapper.like（）：按条件模糊查询
3. 还有很多功能强大的方法，支持动态构建

使用时的关键代码：以User对象的userAccount为例：

1
2
3
QueryWrapper<User> queryWrapper=new QueryWrapper<>();
queryWrapper.eq("userAccount",userAccount);
long count=userMapper.selectCount(queryWrapper);

上述代码的意思是，按照变量userAccount的值，查询数据库User表中字段“userAccount”，并返回与值相同的数据个数。

单元测试 | 注册逻辑

编写注册逻辑的单元测试

功能开发 | 登录功能

  1. 接收参数：用户账号、用户密码
  2. 校验用户的账号、密码、校验码是否符合格式，账号是否重复
  3. 对用户账号与密码在数据库中进行匹配：
    1. 若成功，则先将用户信息脱敏，然后从request取得用户的登录态（session），然后将用户信息保存在session中，并将session保存在服务器上（Springboot封装的tomcat，这一步应该由Spring自动完成），设置session失效时间。最后返回用户信息（脱敏后的）。
    2. 若失败，则返回null，表示登录失败。

session与cookie——服务器如何知道是哪个用户登录了？

  1. 连接服务器时（未进行登录操作），服务器得到一个session（匿名会话），并返回给前端。
  2. 登录成功后，服务器重新取得session并保存，并在session中添加用户信息（K-V格式），返回给前端一个cookie，并要求前端将cookie保存在浏览器。cookie中含有JSESSIONID，对应着唯一的session。
  3. 前端再次发送请求时（相同的域名），在请求头中带上cookie去请求。
  4. 服务器通过cookie与session的对应关系，找到session，从而辨认用户。

session与cookie的生效范围

  1. 后端服务器有各自的域名，例如baidu.com，本机则是localhost。
  2. cookie的生效范围是与域名绑定的，浏览器不区分端口。
  3. session不仅区分域名，还区分端口，同一域名下不同端口的session也是独立的，因此返回的cookie值也是不同的。
  4. 于是可以得出：
    • 向指定的域名发送请求（无论端口），浏览器就会带上对应域名的cookie
    • 接收到同一域名的不同端口返回的cookie，后接收到的cookie会覆盖掉前接收的。
  5. 综上所述均是默认情况，实际情况可以根据需求，灵活调整 cookie|session 与 域名|端口 的绑定关系。

功能开发 | 登录注册接口

application.yml 指定接口全局api（相当于在所有接口的@RequestMapping()前加上了”/api“)

1
2
3
server:
  servlet:
    context-path: /api

登录接口逻辑简单。这里只写一些编写规范。

接口编写规范：

  1. @RestController：Spring 框架识别到这是一个接口，那么接口返回的所有数据都将自动转为 JSON 格式。

  2. GET请求的参数放在请求头中，接受参数使用@RequestParam注解；POST请求的参数放在请求体中，接收参数使用@RequestBody注解

  3. @RequestBody：常用于处理POST请求。使用后，Spring 会自动把请求体的 JSON 化数据转换为 Java 对象（请求体的JSON化由前端完成）。我们需要自己封装RequestBody请求体类用来接收数据，且要实现Serialization接口。Spingboot会自动实现JSON数据的key与RequestBody类的成员变量的映射（需要同名）

    以用户注册接口为例：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    //用于封装用户注册的参数的RequestBody
    @Data
    public class UserLoginRequest implements Serializable {

        private static final long serialVersionUID = 5743377063917044862L;
        private String userAccount;
        private String userPassword;
    }

    //前端请求体
    {
      "userAccount": "Michael",
      "userPassword": "0123456789"
    }

    //后端接口
    @PostMapping("/doLogin")
    public User doLogin(@RequestBody UserLoginRequest userLoginRequest, HttpServletRequest httpServletRequest){
      String userAccount=userLoginRequest.getUserAccount();
      String userPassword=userLoginRequest.getUserPassword();
    }

  4. @RequestParam：常用于处理GET请求。用来从 URL 或请求体中获取特定的参数并将其绑定到方法参数中，两个参数之间要同名，且参数的类型有限制，一般不能是自定义的类，只能是：基本数据类型、List、Map、Date等。

    还提供了两个十分常用的属性：

    • dafaultValue：默认值
    • required：默认情况下，@RequestParam 会将请求中缺失的参数视为错误，抛出 400 错误（Bad Request）。如果某个参数是可选的，可以使用 required 属性来控制。

  5. 接口尽可能少的涉及业务逻辑，除非业务逻辑真的很简单，否则还是将逻辑写在service中。

  6. Controller会使用到的注解：

    1. @RestController
    2. @RequestMapping
    3. @Resource
    4. @PostMapping、@GetMapping等
    5. @RequestBody、@RequestParam

单元测试 | 登录注册接口

IDEA自带HTTP测试工具（无敌了666）：工具 => HTTP客户端 => 在HTTP客户端中创建请求 => 添加请求

使用示例：

1
2
3
4
5
6
7
8
9
10
11
12
//post请求
POST http://localhost:8080/user/doLogin
Content-Type: application/json

{
  "userAccount": "Michael",
  "userPassword": "0123456789"
}

//get请求
GET http://localhost:8080/user/selectUserByNickname?nickname=ciallo
Accept: application/json

功能开发 | 用户管理接口

用户管理逻辑中一定要有鉴权！！，保证只有管理员可以调用这些接口

  1. 查询用户
    1. 按昵称查询（模糊查询）
  2. 删除用户

单元测试 | 用户管理接口

同样使用IDEA的HTTP测试功能。

优化代码

前端开发

Ant Design Pro初始化的项目已经是一套现成的前端系统，有登录页面以及主页，在此基础上进行开发将很方便

前端开发 | 登录页面

  1. 修改页面的展示内容

  2. 修改用到的参数名、参数类型，与后端接口保持一致

  3. 修改登录API的请求路径，调用自己的后端接口：src/services/ant-design-pro/api.ts

  4. 开启代理解决跨域问题：config/proxy.ts

    配置代理:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    dev: {
        // localhost:8000/api/** -> https://preview.pro.ant.design/api/**
        '/api/': {
          // 要代理的地址
          target: 'http://localhost:8080',
          // 配置了这个可以从 http 代理到 https
          // 依赖 origin 的功能可能需要这个，比如 cookie
          changeOrigin: true,
        },
      },

    这样的配置可以将以“/api”开头的请求（根路径为http://localhost:8000，即前端项目根路径）代理到http://localhost:8080（后端项目根路径）

  5. Umi默认开启token，即Umi会自动在请求头上加入token，这会导致请求路径与后端接口不匹配（后端暂时还未考虑token功能），因此需要关闭：

    在src/requestErrorConfig.ts将下面这段配置注释掉：

    1
    2
    3
    4
    5
    6
    7
    8
    // 请求拦截器
      requestInterceptors: [
        (config: RequestOptions) => {
          // 拦截请求配置，进行个性化处理。
          const url = config?.url?.concat('?token = 123');
          return { ...config, url };
        },
      ],

单元测试 | 登录功能

测试登录功能是否能在前后端之间联通

前端开发 | 注册页面

  1. 注册页面与登录页面样式类似，直接先复制src/pages/User/Login再做修改：

    1. 修改页面的展示内容

      • 需要将button上的“登录”改成“注册”

        /Login/index.tsx页面中找不到设置button的内容，因为button是被封装在LoginForm中的。

      • 追溯LoginForm 的源码：

        1. ctrl+B追溯到LoginForm源码的ts文件，alt+f1选择项目视图 ，可以快速定位的到文件的路径：node_modules/@ant-design/pro-form/es/layouts/LoginForm/index.d.ts

        2. 在同目录下，找到LoginForm源码的js文件

        3. js源码中有这样一段代码定义了button的内容：

          1
          2
          3
          4
          var submitter = proFormProps.submitter === false ? false : _objectSpread(_objectSpread({
            searchConfig: {
              submitText: intl.getMessage('loginForm.submitText', '登录')
            }

          说明LoginForm有一个submitter属性，submitter有一个searchConfig属性，searchConfig有一个submitText属性，规定了button的内容

        4. 回到/Login/index.tsx，设置LoginForm的属性，成功修改button的内容

          1
          2
          3
          4
          5
          6
          7
          8
          9
          <LoginForm
             //修改按钮的内容“登录”为“注册”
             submitter={{
               searchConfig: {
                 submitText: "注册"
               }
             }}
            ...
          >...</LoginForm>

    2. 修改用到的参数名、参数类型，与后端接口保持一致 => （其实这一步挺难的，因为Ant Design Pro的封装程度太高了，需要很仔细的检查）

    3. 修改页面逻辑

      1. 修改注册API的请求路径
      2. 注册成功后重定向到登录页面
      3. Ant Design Pro默认：若当前为非登录页面且用户信息为空时，会自动重定向到登录页面。我们需要修改这段逻辑，使得当前页面为注册页面时，前端不会自动重定向。这段逻辑在src/app.tsx的getInitialState()函数中。

  2. 配置路由config/routes.ts，使得浏览器可以访问到新建的注册页面

app.tsx是前端项目的全局入口文件，里面定义了许多的全局公共信息，十分重要

  1. getInitialState()：页面加载时调用，作用：查询当前用户登录态，若无（即session为空），则重定向到登录页面；若有（即session不为空），则查询当前用户信息并返回给前端，赋值给前端的一个全局变量：currentUser
  2. layout()：控制页面的全局布局

单元测试 | 注册功能

测试注册功能是否能在前后端之间联通

功能开发 | 获取用户登录态

实现获取用户登录态，若用户再次打开网页时（session有效期间），不用重复登录，后端就知道是哪个用户在访问。

  1. 编写后端接口getCurrrentUser():User：在用户第一次登录时，我们已经将登录成功的用户信息存放在了session中。因此，只需要再次从session中取出用户信息，并根据id从数据库中重新获取（session中存放的是第一次登录时的用户信息，但是在两次登录之间，用户的某些数据可能已经改变）并返回。若session为空，说明没有用户登录，接口返回null，前端逻辑会重定向到登录页面。

  2. 修改代码，使前后端接口的返回数据类型保持一致

    1. src/services/ant-design-pro/api.ts这个文件中定义了所有前端对后端接口的调用，查询当前用户的调用为currentUser()，其返回的是一个{data: API.CurrentUser}的对象，其有一个成员data，类型是API.CurrentUser。而后端返回的是一个User类型的数据，{data: API.CurrentUser}与User显然不匹配，因此我们要进行修改：

      1. {data: API.CurrentUser}修改为API.CurrentUser，即直接将User赋给API.CurrentUser，确认前端API.CurrentUser与后端User的对应关系

      2. 修改API.CurrentUser的结构，与User保持一致，Ant Design Pro会自动建立同名字段的联系

      3. 修改用到{data: API.CurrentUser}和API.CurrentUser的其他处代码

开发进行到这里时，我们注册并登录账号后，就可以进入到系统主页。

​

完整登录注册逻辑：

  1. 注册
  2. 第一次登录，后端校验账号密码正确，将User存放在session中，返回校验成功的信息给前端，以及cookie。
  3. 前端接收返回后重新加载页面，调用getInitialState()，getInitialState()调用queryUserInfo()向后端请求获取当前用户信息User并附带cookie
  4. 后端由cookie找到对应的session，并取出用户信息。
  5. 后端根据用户身份信息，重新从数据库中获取一次用户最新信息User，返回User给前端
  6. getInitialState()根据User信息，重定向到用户主页，第一次登录成功。
  7. session有效期间，不用重复登录即可访问主页

功能开发 | 用户管理

Ant Design Pro也为前端页面访问提供了简单的权限管理手段，通过路由routes.ts为页面配置access属性即可。

校验权限的逻辑在src/access.ts。

用户管理页面开发

**一个 CRUD 页面 = ProLayout+ ProTable + Form **

ProLayout - 高级布局

ProLayout 可以提供一个标准又不失灵活的中后台标准布局，同时提供一键切换布局形态、自动生成菜单等功能。与 PageContainer 配合使用可以自动生成面包屑、页面标题。

在Ant Design Pro中，ProLayout配置在config.ts中，默认全局开启，即每个页面都在应用。

页面可以在routes.ts中通过layout属性来单独配置是否开启ProLayout，例如：登录注册页面都不需要，就可以设置layout: false

  1. 一键切换布局形态：通过页面右侧抽屉UI界面一键切换。

  2. 自动生成菜单：所有页面，每个页面都作为一个菜单项，根据在路由文件routes.ts中路由的层级关系来生成菜单并显示在页面侧边。

    但是也可以通过在routes.ts中配置属性来个性化菜单显示，具体可参考官方文档。

  3. 面包屑：显示当前页面在系统层级结构中的位置，并能向上返回。需要用<PageContainer></PageContainer>包裹住页面的HTML部分，面包屑才会生效。

ProTable - 高级表单

ProComponents提供了一系列封装好的前端组件，只需要在官网搜索样式复制代码再修改即可。这里用到的是ProTable组件

  1. 复制ProTable的代码作为UserManage的页面：src/pages/Admin/UserManage/index.tsx。配合ProLayout，就能得到一个CRUB页面

  2. 为页面配置路由

  3. 编写后端接口

  4. 修改页面代码，设计符合需求的表单

    1. 需求：表格显示所有用户的信息，且能根据条件搜索特定用户

    2. 通过columns定义表格有哪些列，列的属性：

      • dataIndex：列的类型，与User的成员字段对应

      • title：显示的名称

      • render：如果是图片，例如头像，则需要渲染

        1
        2
        3
        4
        5
        render: (_, record) => (
              <div>
                <Image src={record.avatar} width={50}/>
              </div>
            ),

      • valueType：用来指定列的数据类型。ProTable 支持多种 valueType，如 text、date、money 等，可以通过此属性来启用格式化和特定行为。

      • valueEnum：为数据的值与含义建立对应关系，例如数据中userRole的枚举值为{0,1}，分别代表普通用户与管理员。

        框架会根据stauts的值为数据添加颜色，default为灰色，success为绿色，error为红色

        1
        2
        3
        4
        5
        6
        7
        8
        9
        10
        valueEnum: {
          0: {
            text: '普通用户',
            status: 'default',  
          },
          1: {
            text: '管理员',
            status: 'success',
          },
        },

      • 。。。（其他）

    3. 定义查询用户信息的接口API。

      1
      2
      3
      4
      5
      6
      7
      8
      /** 查询用户 GET /api/user/selectUser */
      export async function selectUserByNickname(options?: { [key: string]: any }) {
        return request<API.CurrentUser[]>('/api/user/selectUser', {
          method: 'GET',
          //...(options || {}),
          params: options,
        });
      }

      • options?: { [key: string]: any }：这是函数的一个参数，叫做 options。

      • options? 的意思是 该参数是可选的，即调用该函数时可以选择传入该参数，也可以不传入。

      • { [key: string]: any } 是一个 索引签名，意味着 options 可以是一个 对象，对象的键（key）是字符串类型，值（value）可以是任意类型。这使得 options 可以接收任何属性和对应的值。例如，options 可以是 { nickname: 'JohnDoe', age: 30 }。

      • params: options 表示将options作为 params 显式传递给 request 函数，request会自动将它转化为 URL 查询字符串，添加到请求 URL 后面

      • ...(options || {}) 这是原本框架的代码，使用了展开运算符，将 options 对象的属性直接添加到请求配置对象中，但 options 只是直接展开到配置对象，而没有明确指定为 params，当请求是 GET 时，后端可能会接受不到参数，所以被注释掉，并改为使用显式传递。

    4. 调用定义好的接口

      下面这段代码在<ProTable>...</ProTable>源码中，其功能就是发送查询用户信息的请求。

      1
      2
      3
      4
      5
      6
      7
      8
      9
      request={async (params, sort, filter) => {
           console.log(sort, filter);
           await waitTime(2000);
           return request<{
             data: GithubIssueItem[];
           }>('https://proapi.azurewebsites.net/github/issues', {
             params,
           });
         }}

      现在结合上面定义好的接口，对其修改

      1
      2
      3
      4
      5
      6
      7
      8
      request={async (params, sort, filter) => {
           console.log(sort, filter);
           // await waitTime(2000);
           const list = await selectUserByNickname(params);
           return {
             data: list
           }
         }}
      • params 是从搜索表单收集到的查询条件，它是一个键值对对象，可以直接传入接口中

最终效果

  1. 在调出管理页时，Ant Design Pro会自动发送一次查询请求，表格中就能显示所有用户信息。

    image-20250125020215382

  2. 也可以根据上方的搜索栏，按条件查询用户

    image-20250125020135998

功能开发 | 用户注销

EZ

  1. 前端逻辑在src/components/RightContent/AvatarDropdown.tsx中
  2. 编写后端接口，只要将session的用户信息清空即可。

后端优化

所有的优化都要明确目的。

数据返回、异常处理

  1. 定义通用返回类BaseResponse<T>

    • 目的：给返回对象添加信息，告诉前端这个请求在业务层面上是成功还是失败

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      @Data
      public class BaseResponse<T> implements Serializable {

        private int code;
        private T data;
        private String message;
        private String description;

        //构造函数
        ...
      }
      • code：错误码
      • data：数据，是泛型，增强通用性
      • message：解释
      • description：更细节的解释

  2. 定义异常错误码 ErrorCode

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    public enum ErrorCode {
      PARAM_ERROR(4000,"请求参数不合法",""),
      PARAM_NULL(4001,"请求参数为空",""),
      ACCESS_ERROR(3000,"权限不足",""),
      NOT_LOGIN(3001,"未登录",""),
      UNKNOWN_ERROR(6000,"未知异常",""),
      SYSTEM_ERROR(5000,"系统内部错误",""),
      DATABASE_ERROR(3002,"数据库操作失败","");

      private final int code;
      private final String message;
      private final String description;
    }

  3. BaseResponse<T>与Errorcode配合使用

    为BaseResponse添加构造函数constructor，传入ErrorCode作为param

    1
    2
    3
    4
    5
    public BaseResponse(ErrorCode errorCode){
      this.code=errorCode.getCode();
      this.message=errorCode.getMessage();
      this.description=errorCode.getDescription();
    }

  4. 定义一个工具类ResultUtil用来创建BaseResponse

    • 目的：代码更简洁、容易阅读
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    public class ResultUtil {

      public static <T> BaseResponse<T> success(T data ){
        return new BaseResponse<>(2000,data,"ok");
      }

      public static <T> BaseResponse<T> error(ErrorCode errorCode){
        return new BaseResponse<>(errorCode);
      }
      ...
    }

  5. 封装全局异常处理：

    1. 定义业务异常类BusinessException

      • 目的：相比与Java自带的异常类，description能够记录更多的信息。
      • 在抛出异常时，用description记录详细的报错信息
      1
      2
      3
      4
      5
      6
      public class BusinessException extends RuntimeException{

        private final int code;
        private final String description;

      }
      • 父类RuntimeException中有成员变量message，所以不用再定义

    2. 编写全局异常处理器GlobalExceptionHandler

      • 捕获所有的异常，无论是业务相关的异常还是系统内部的异常，无论是在controller还是在service中，
      • 目的是：
        • 集中处理业务相关的异常，让前端知道更详细的报错信息
        • 对前端屏蔽系统内部的异常，不暴露服务器内部信息
        • 集中记录日志
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      @RestControllerAdvice
      @Slf4j
      public class GlobalExceptionHandler {

        @ExceptionHandler(BusinessException.class)
        public BaseResponse businessExceptionHandler(BusinessException e){
          log.error("BusinessException: "+e.getMessage()+":"+e.getDescription());
          return ResultUtil.error(e.getCode(),e.getMessage(),e.getDescription());
        }

        @ExceptionHandler(RuntimeException.class)
        public BaseResponse runtimeExceptionHandler(RuntimeException e){
          log.error("RuntimeException: "+e.getMessage());
          return ResultUtil.error(ErrorCode.SYSTEM_ERROR);
        }
      }

    • @ExceptionHandler(BusinessException.class)表示只捕获BusinessException类型的异常

  6. 完成后，例如：当出现有封禁用户试图登录时，后端控制台就会打印异常日志：

    2025-01-27 22:22:34.967 ERROR 22600 --- [nio-8080-exec-7] c.m.u.exception.GlobalExceptionHandler : BusinessException: 请求参数不合法:账号已被封禁

  7. 修改前端相应代码

完整逻辑：

  1. 出现错误，有不同的错误类型ErrorCode，再根据具体情况记录详细信息description，构建并抛出BusinessException
  2. Handler捕获异常，集中处理，记录日志
  3. 在Handler中使用ResultUtil创建BaseResponse，返回给前端

功能完善

  1. 用户信息删除
  2. 用户信息修改
  3. 支持更多查询条件

项目部署

多环境理论

  1. 什么是多环境？

    • 指同一套代码在不同的阶段根据实际需要调整配置并部署到不同的机器上

  2. 为什么需要多环境？

    • 每个环境互不影响
    • 区分不同的阶段：开发、测试、生产
    • 对项目进行优化
      • 本地日志级别
      • 精简依赖，减小项目体积
      • 项目的环境/参数可以调整，比如JVM参数
    • 针对不同的环境做不同的事情

  3. 多环境分类：

    • 本地环境
    • 开发环境（远程开发），多人同时连一台机器，同时开发
    • 测试环境，独立的数据库、独立的服务器
    • 预发布环境：（体验服）与正式服一致，数据库一致
    • 正式环境（公开对外的环境）

前端多环境实战

Ant Design Pro官方文档中，详细了介绍多环境方法

在开发中经常会有一些需求，根据应用运行的不同环境进行不同的逻辑处理。

比如，dev 环境使用 dev 的对应的 Url，而线上则使用 prod 对应的 Url。 或者，在某些特定的环境需要打开只有在该环境下才会生效的功能。

获取当前运行环境名称

在 Pro 的脚手架中有这样的一个环境变量 REACT_APP_ENV，该变量代表当前应用所处环境的具体名称。如 dev、test、pre、prod 等。

如若需要在 config 外的非 node 环境文件中使用该环境变量，则需要在 config 导出默认 defineConfig() 时配置 define{}。

示例代码如下：

1
2
3
4
5
6
7
8
9
10
// config/config.ts
const { REACT_APP_ENV } = process.env;

export default defineConfig({
{/** 省略其他配置 */}
define: {
  REACT_APP_ENV: REACT_APP_ENV || false,
}
{/** 省略其他配置 */}
});

使用该变量示例代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// src/components/RightContent/index.tsx
/** 省略其他代码 */
const GlobalHeaderRight: React.FC<{}> = () => {
/** 省略其他代码 */
return (
  <Space className={className}>
    <!-- 省略其他代码 -->
    <!-- 在顶部右侧显示对应环境名称 -->
    {REACT_APP_ENV && (
      <span>
        <Tag color={ENVTagColor[REACT_APP_ENV]}>{REACT_APP_ENV}</Tag>
      </span>
    )}
  </Space>
);
};

多环境多份配置文件

Pro 脚手架默认使用 Umi 作为底层框架，在 Umi 内可通过指定 UMI_ENV 环境变量来区分不同环境的配置文件，UMI_ENV 需要在 package.json 内配置。

示例配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
{/** 省略... */}
"scripts": {
  "analyze": "cross-env ANALYZE=1 umi build",
  "build": "umi build",
  "build:dev": "cross-env REACT_APP_ENV=dev UMI_ENV=dev umi build",
  "build:test": "cross-env REACT_APP_ENV=test UMI_ENV=test umi build",
  "build:pre": "cross-env REACT_APP_ENV=pre UMI_ENV=pre umi build",
  "build:prod": "cross-env REACT_APP_ENV=prod UMI_ENV=prod umi build",
  "deploy": "npm run site && npm run gh-pages",
  "dev": "npm run start:dev",
  {/** 省略... */}
  "start": "cross-env REACT_APP_ENV=dev UMI_ENV=dev umi dev",
  "start:dev": "cross-env REACT_APP_ENV=dev UMI_ENV=dev MOCK=none umi dev",
  "start:no-mock": "cross-env REACT_APP_ENV=dev UMI_ENV=dev MOCK=none umi dev",
  "start:no-ui": "cross-env REACT_APP_ENV=dev UMI_ENV=dev UMI_UI=none umi dev",
  "start:pre": "cross-env REACT_APP_ENV=pre UMI_ENV=pre MOCK=none umi dev",
  "start:test": "cross-env REACT_APP_ENV=test UMI_ENV=test MOCK=none umi dev",
  {/** 省略... */}
},
	{/** 省略... */}
}

当 UMI_ENV 为 test 时，则必须在 config 目录下配置 config.test.ts 文件来管理 test 环境下的不同变量，Umi 框架会在 deep merge 后形成最终配置。

示例代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
// config/config.test.ts test环境对应的配置文件
import { defineConfig } from 'umi';

/**
 * 导出的多环境变量命名约定：一律大写且采用下划线分割单词
 * 注意：在添加变量后，需要在src/typing.d.ts内添加该变量的声明，否则在使用变量时IDE会报错。
 */
export default defineConfig({
  define: {
    API_URL: '/test', // API地址
    API_SECRET_KEY: 'XXXXXXXXXXXXXXXX', // API调用密钥
  },
});

变量使用示例：

1
2
3
4
5
6
7
8
9
// src/services/user.ts
import { request } from 'umi';

export async function query() {
  // 使用API密钥调用用户接口
  return request<API.CurrentUser[]>('${API_URL}/api/users', {
    API_SECRET_KEY,
  });
}

配置文件夹 config 下的结构：

1
2
3
4
5
6
7
8
9
10
11
ant-design-pro
├── config
│   ├── config.dev.ts
│   ├── config.test.ts
│   ├── config.pre.ts
│   ├── config.prod.ts
│   ├── config.ts
│   ├── proxy.ts
│   ├── routes.ts
│   ├── defaultSettings.ts
...

Ant Design Pro使用 REACT_APP_ENV 变量来代表当前所处的环境:

  • npm run start时，REACT_APP_ENV == dev
    • 本地启动、监听端口、自动更新
  • npm run build时，REACT_APP_ENV == prod
    • 项目打包构建
    • Terminal使用serve工具启动（npm i -g serve)
    • 不会自动更新，因为代码不会更改了

后端多环境

服务器选择：CentOS 7.6 以上

不同的环境加载不同的配置文件:

  • application.yml：通用配置，所有环境启动都会加载
  • application.yml：只有开发环境启动才会加载
  • application-prod.yml：只有生产环境启动才会加载

项目打包成 jar 包 :

  • IDEA => maven => Lifecycle => package

Terminal运行jar包：

  • java -jar {JAR_PATH}

  • 可以后接不同的参数，例如：

    • --spring.profiles.active=prod
    • --server.port=8081

部署方式 | Nginx + Springboot

总结

体会：新学一个框架，多看官方文档

知识点：

  1. 学习了Ant Design Pro前端项目的代码结构，理解了一些重要文件在整个项目的作用

    • config.ts：全局配置文件

    • routes.ts：路由配置

    • proxy.ts：代理配置

    • package.json ：项目启动命令

    • app.ts：项目入口文件

    • api.ts：请求方法API

    • access.ts：前端权限校验

    • typings.d.ts：自定义数据类型

    • index.tsx：页面文件

  2. MyBatis X：代码生成

  3. 数据库表必备三字段：createTime、updateTime、isDelete

  4. Controller层的几个注解：

    • @RestController：Spring 框架识别到这是一个接口，那么接口返回的所有数据都将自动转为 JSON 格式。
    • @RequestBody：常用于处理POST请求。使用后，Spring 会自动把请求体的 JSON 化数据转换为 Java 对象（请求体的JSON化由前端完成）。我们需要自己封装RequestBody请求体类用来接收数据，且要实现Serialization接口。Spingboot会自动实现JSON数据的key与RequestBody类的成员变量的映射（需要同名）
    • @RequestParam：常用于处理GET请求。用来从 URL 或请求体中获取特定的参数并将其绑定到方法参数中，两个参数之间要同名，且参数的类型有限制，一般不能是自定义的类，只能是：基本数据类型、List、Map、Date等。

  5. 使用自定义请求实体类用来接收请求参数

  6. 如何维护用户登录态——session与cookie

  7. session与cookie的生效范围

  8. 熟悉了ProTable组件

  9. 前端虽然不懂具体的语法，但是明白 ”可以在哪些地方完成哪些功能“ ，具体的代码可以百度或GPT

  10. 熟悉了后端 通用返回 以及 异常处理 的一整套模式

待拓展点：

  1. 单机登录改为分布式登录（已在伙伴匹配项目实现）
  2. 后端添加全局请求拦截器（统一判断用户权限，统一记录请求日志）
  3. 用户管理的查询用户业务，改为分页查询实现（已在伙伴匹配项目实现），避免数据量过多。

展开全文 >>

基于数据库的分布式锁方案

基于数据库的分布式锁方案：

  1. 锁的表结构

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    CREATE TABLE `resource_lock`
    (
      `keyResource` varchar(45) COLLATE utf8_bin NOT NULL DEFAULT '资源主键',
      `lockStatus`       char(1) COLLATE utf8_bin     NOT NULL DEFAULT '' COMMENT 'S-成功,F-失败,P-过期',
      `lockFlag`    int(10) unsigned             NOT NULL DEFAULT '0' COMMENT '1是已经锁 0是未锁',
      `beginTime`   datetime                              DEFAULT NULL COMMENT '开始时间',
      `endTime`     datetime                              DEFAULT NULL COMMENT '结束时间',
      `UUID`    char(36) COLLATE utf8_bin NOT NULL DEFAULT '抢到锁的节点的UUID',
      `time`         int(10) unsigned             NOT NULL DEFAULT '60' COMMENT '方法生命周期内只允许一个结点获取一次锁，单位：分钟',
      PRIMARY KEY (`keyResource`) USING BTREE
    ) ENGINE = InnoDB
      DEFAULT CHARSET = utf8
      COLLATE = utf8_bin

  2. ResourceMapper.xml 自定义 SQL 语句 :

    使用select for ... update：查询数据的同时为数据加写锁，直到事务提交时释放。

    注意，在Springboot+Mybatis中，数据源底层为每一次数据库操作（包括查询操作，即使它不修改数据）都自动执行了事务提交操作，所以在下面的 service层 要使用 @Transactional 关闭自动提交，否则一加上锁就会被立刻释放。

    • **getLock(Param:keyResource)**：

      1
      2
      3
      4
      5
      <select id="getLock" parameterType="java.lang.String" resultType="com.michael.usercenter.model.domain.ResourceLock">
          select * from 'resource_lock'
          where keyResource = #{keyResource,jdbcType=VARCHAR}
              for update
      </select>

  3. ResourceLockService 接口设计：（仿照Redisson，设计 getLock 和 tryLock 的原因在上面 Redisson分布式锁小节有解释）

    • **ResourceLock: getLock(String keyResource)**：

      1. @Transactional：主要的作用是关闭自动提交。

        如果不关闭自动提交，在下面调用mapper.getLock()中，select for update本身也会触发事务提交，导致锁立刻失效。

      2. 调用mapper.getLock()，返回数据库中资源的锁lock

      3. 如果lock为空，则创建lock:

        1. keyResource设为当前资源key
        2. status设为 S
        3. lockFlag设为1
        4. beginTime设为当前时间
        5. time数据库默认为60min，表示锁的生效时长
        6. endTime=beginTime+time
        7. 生成UUID并填入
        8. 向数据库中更新lock

      4. 返回lock

    • boolean: tryLock(String keyResource, int waitTime, int leaseTime):

      1. @Transactional
      2. 开始waitTime计时：
        1. 调用mapper.getLock()，获取lock
        2. 检查lock的字段：
          1. 如果lockFlag为1且status为P，表示正在被占用，如果计时还未结束，则重复上一步
          2. 如果lockFlag为1且status为F，表示正在被占用但是已经过期，如果计时还未结束，则重复上一步（TODO 锁的过期管理机制）
          3. 如果lockFlag为0且status为S，表示锁空闲，进行下一步
        3. 如果计时结束，则直接返回false
      3. 如果锁空闲：
        1. beginTime设为当前时间
        2. time设为leaseTime的值
        3. endTime=beginTime+time
        4. lockFlag设为1
        5. status设为P
        6. 生成UUID并填入
        7. 向数据库中更新lock
        8. 返回true

    • boolean: lock(String keyResource, int leaseTime):

      TODO

    • void: unlock(String keyResource, String UUID):

      unlock() 相当于 Redisson 的 isHeldByCurrentThread() + unlock()，但是 Redisson 用 lua 脚本保证了这一组合的原子性。这里不打算引入 lua 脚本，所以整合为一个方法，配合行级锁来保证原子性。

      1. @Transactional
      2. 调用mapper.getLock()，得到lock
      3. 将lock.UUID与 UUID 比较。
      4. 如果相等：
        1. lockFlag设为0
        2. status设为S
        3. 向数据库更新lock
      5. 如果不等，则直接返回

展开全文 >>

智能协同云图库-readme

[TOC]

智能协同云图库

基于 Vue3 + Springboot + COS + AI 的个人云端图片素材库

核心功能：

  1. 所有用户在可以网站上快速上传和检索图片
  2. 管理员可以上传、审核和管理图片，并对系统内的图片进行分析
  3. （待实现）对于个人用户，可以将图片上传至私有空间进行批量管理、检索、编辑和分析，用作个人网盘、个人相册、作品集等
  4. （待实现）对于企业，可以开通团队空间并邀请成员，共享图片并实时协同编辑图片，提高团队效率，可用于提供商业服务

项目开发阶段

  1. 第一阶段：开发公共的图库平台。实战 Vue3 + Springboot 图片素材网站的快速开发。学习文件存管业务的开发和优化技巧。
  2. 第二阶段：对项目的C端进行大量扩展。用户可以开通私有空间，并对空间图片进行多维检索、扫码分享、批量管理、快速编辑、用量分析。该阶段涉及大量主流业务功能开发，能学到很多业务知识和开发经验。
  3. 第三阶段：对项目的B端进行大量扩展。企业可以开通团队空间。

技术选型

后端：

  • Java Springboot
  • MySQL + Mybatis-plus+ Mybatis X
  • Redis 分布式缓存 + Caffeine 本地缓存
  • Jsoup 数据抓取
  • COS 对象存储

后端初始化 | 通用基础模版

实现了一个后端通用基础模版。使用到的依赖：Spring Boot DevTools、Spring Configuration Processor、SpringWeb、MYSQL、Mybatis-Plus、Lombok、Hutool、Knife4j、AOP。

JDK 推荐使用 11 版本，因为后续可能要用到的缓存库 Caffeine 要求使用 11 版本。

需要安装的插件：Mybatis X 代码生成工具

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
<dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>com.mysql</groupId>
            <artifactId>mysql-connector-j</artifactId>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-configuration-processor</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>com.baomidou</groupId>
            <artifactId>mybatis-plus-boot-starter</artifactId>
            <version>3.5.10.1</version>
        </dependency>
        <dependency>
            <groupId>cn.hutool</groupId>
            <artifactId>hutool-all</artifactId>
            <version>5.8.26</version>
        </dependency>
        <dependency>
            <groupId>com.github.xiaoymin</groupId>
            <artifactId>knife4j-openapi2-spring-boot-starter</artifactId>
            <version>4.4.0</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-aop</artifactId>
        </dependency>
        
    </dependencies>

模板的 src 目录结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
├─src
│  ├─main
│  │  ├─java
│  │  │  ├─com
│  │  │  │  └─example
│  │  │  │      └─michaelpicturebackend
│  │  │  │          │  MichaelPictureBackendApplication.java
│  │  │  │          │
│  │  │  │          ├─common
│  │  │  │          │      BaseResponse.java
│  │  │  │          │      DeleteRequest.java
│  │  │  │          │      PageRequest.java
│  │  │  │          │      ResultUtils.java
│  │  │  │          │
│  │  │  │          ├─config
│  │  │  │          │      CorsConfig.java
│  │  │  │          │
│  │  │  │          ├─controller
│  │  │  │          ├─exception
│  │  │  │          │      BusinessException.java
│  │  │  │          │      ErrorCode.java
│  │  │  │          │      GlobalExceptionHandler.java
│  │  │  │          │      ThrowUtils.java
│  │  │  │          │
│  │  │  │          └─mapper
│  │  │  └─generator
│  │  │      ├─domain
│  │  │      │      User.java
│  │  │      │
│  │  │      ├─mapper
│  │  │      │      UserMapper.java
│  │  │      │
│  │  │      └─service
│  │  │          │  UserService.java
│  │  │          │
│  │  │          └─impl
│  │  │                  UserServiceImpl.java
│  │  │
│  │  └─resources
│  │      │  application.yml
│  │      │
│  │      ├─mapper
│  │      │      UserMapper.xml
│  │      │
│  │      └─static
│  │              index.html
│  │
│  └─test
│      └─java
│          └─com
│              └─example
│                  └─michaelpicturebackend
│                          MichaelPictureBackendApplicationTests.java

application.yml配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
spring:
  application:
    name: michael-picture-backend
  # MYSQL 数据库
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/michael_picture
    username: root
    password: zmx004200412

server:
  port: 8080
  servlet:
    context-path: /api

mybatis-plus:
  configuration:
    map-underscore-to-camel-case: false
    # 仅在开发环境开启日志
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: isDelete # 全局逻辑删除字段名
      logic-delete-value: 1 # 逻辑已删除值
      logic-not-delete-value: 0 # 逻辑未删除值

# knife4j接口文档配置
knife4j:
  enable: true
  # 开启登录认证
  basic:
    enable: true
    username: admin
    password: 123456
  openapi:
    title: "接口文档"
    version: 1.0
    group:
      default:
        api-rule: package
        api-rule-resources:
          - com.example.michaelpicturebackend.controller

数据库设计

用户表 user

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
-- 用户表
create table if not exists user
(
    id           bigint auto_increment comment 'id' primary key,
    userAccount  varchar(256)                           not null comment '账号',
    userPassword varchar(512)                           not null comment '密码',
    userName     varchar(256)                           null comment '用户昵称',
    userAvatar   varchar(1024)                          null comment '用户头像',
    userProfile  varchar(512)                           null comment '用户简介',
    userRole     varchar(256) default 'user'            not null comment '用户角色：user/admin',
    editTime     datetime     default CURRENT_TIMESTAMP not null comment '编辑时间',
    createTime   datetime     default CURRENT_TIMESTAMP not null comment '创建时间',
    updateTime   datetime     default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '更新时间',
    isDelete     tinyint      default 0                 not null comment '是否删除',
    UNIQUE KEY uk_userAccount (userAccount),
    INDEX idx_userName (userName)
) comment '用户' collate = utf8mb4_unicode_ci;

  1. editTime 和 updateTime 的区别：editTime 表示用户编辑个人信息的时间（需要业务代码来更新），而 updateTime 表示这条用户记录任何字段发生修改的时间（由数据库自动更新）。

  2. 给唯一值添加唯一键（唯一索引），比如账号 userAccount，利用数据库天然防重复，同时可以增加查询效率。

  3. 给经常用于查询的字段添加索引，比如用户昵称 userName，可以增加查询效率。

后端开发 | 用户模块

需求分析

基础的注册登录、管理员的增删改查等

数据模型开发 | 实体类

Mybatis X 生成的代码一般不能直接满足我们的需求。例如我们需要自定义主键生成策略、指定逻辑删除字段：

  1. 数据中 id 的默认生成策略是自增，容易被爬虫抓取，所以更换策略为ASSIGN_ID雪花算法生成
  2. @TableLogic指定逻辑删除字段
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@TableName(value ="user")
@Data
public class User implements Serializable {
    /**
     * id（要指定主键策略）
     */
    @TableId(type = IdType.ASSIGN_ID)
    private Long id;

    // ...
    
    /**
     * 是否删除（逻辑删除）
     */
    @TableLogic
    private Integer isDelete;
}

数据模型开发 | 枚举类

user 类型中，定义了用户角色字段，用来进行权限管理。这样的角色类型数量是有限的、可枚举的，所以定义一个枚举类，便于在项目中获取值。

在model/enums包下新建UserRoleEnum：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
@Getter
public enum UserRoleEnum {

    USER("用户", "user"),
    ADMIN("管理员", "admin");

    private final String text;

    private final String value;

    UserRoleEnum(String text, String value) {
        this.text = text;
        this.value = value;
    }

    /**
     * 根据 value 获取枚举
     *
     * @param value 枚举值的value
     * @return 枚举值
     */
    public static UserRoleEnum getEnumByValue(String value) {
        if (ObjUtil.isEmpty(value)) {
            return null;
        }
        for (UserRoleEnum anEnum : UserRoleEnum.values()) {
            if (anEnum.value.equals(value)) {
                return anEnum;
            }
        }
        return null;
    }
}

在这里定义的 getEnumByValue() 方法很有意思，使得判断相等的方式变为：

  1. 通过value获取enum对象
  2. 使用equals判断enum对象之间是否相等

这种方式确实蛮优雅。

数据模型开发 | 常量类

在constant下管理常量类，例如用户相关的常量，就定义UserConstant（接口类），在里面声明常量。

引入自己编写的 AOP+自定义注解 的参数校验模块

paramValidator 目录结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
├─paramValidator
│  ├─annotation
│  │      Verify.class
│  │
│  ├─aspect
│  │      EntityValidatorAspect.class
│  │
│  ├─enums
│  │      RegexOption.class
│  │
│  ├─exception
│  │      ParamAssert.class
│  │      ParamExceptionHandler.class
│  │      ParamException.class
│  │
│  └─result
│          Result.class

接下来很多的参数就可以通过注解 @Verify 来实现。

功能开发 | 用户注册

  1. 数据模型

    在model/dto/user下新建UserRegisterRequest：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    @Data
    public class UserRegisterRequest implements Serializable {

        private static final long serialVersionUID = 3191241716373120793L;

        /**
         * 账号
         */
        @Verify(name="userAccount",regular="4-20,不包含特殊字符")
        private String userAccount;

        /**
         * 密码
         */
        @Verify(name="userPassword",regular="8-20,不包含特殊字符")
        private String userPassword;

        /**
         * 确认密码
         */
        @Verify(name="userPassword",regular="8-20,不包含特殊字符")
        private String checkPassword;
    }

  2. 服务设计：

    long userRegister(String userAccount,String userPassword,String checkPassword)

    1. 密码和校验码要相等
    2. 账户名不能重复
    3. 给密码加密（加盐）
    4. 插入数据
    5. 如果插入成功，返回用户ID
    6. 否则报错：操作失败

  3. 接口设计：

    BaseResponse<Long> register(@RequestBody UserRegisterRequest userRegisterRequest)

    1. 如果userRegisterRequest为空则报错：参数不存在
    2. 调用服务
    3. 返回

功能开发 | 用户登录

  1. 数据模型：

    在model/dto/user下新建UserLoginRequest：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    @Data
    public class UserLoginRequest implements Serializable {

        private static final long serialVersionUID = 3191241716373120793L;

        /**
         * 账号
         */
        @Verify(name="userAccount",regular="4-20，不包含特殊字符，且能包含中文")
        private String userAccount;

        /**
         * 密码
         */
        @Verify(name="userPassword",regular="8-20")
        private String userPassword;
    }

    在model/vo下新建返回给前端的用户信息类型LoginUserVo

  2. 服务设计：

    LoginUserVO userLogin(String userAccount,String userPassword,HttpServletRequest request)

    1. 根据用户名和密码（加密处理）查询用户是否存在
    2. 如果不存在则报错：用户名不存在或密码错误
    3. 存在则将用户数据脱敏，写入session的attribute
    4. 返回脱敏的用户数据

  3. 接口设计：

    BaseResponse<LoginUserVO> login(@RequestBody UserLoginRequest userLoginRequest,HttpServletRequest request)

    1. 如果userLoginRequest为空则报错：参数不存在
    2. 调用服务
    3. 返回

功能开发 | 获取当前用户

  1. 数据模型

    不需要

  2. 服务设计:

    User getCurrentUser(HttpServletRequest request)

    1. 从 session 中根据关键字获取保存的用户信息
    2. 如果没有，则说明没有登录，报错：用户未登录
    3. 如果有，说明用户已登录，则根据ID查询用户最新信息后返回
    4. 更新session中用户信息（脱敏）
    5. 返回

  3. 接口设计：

    BaseResponse<LoginUserVO> getCurrentUser(HttpServletRequest request)

    1. 调用服务
    2. 信息脱敏
    3. 返回

功能开发 | 用户退出登录

  1. 数据模型

    无

  2. 服务设计：

    boolean userLogout(HttpServletRequest request)

    1. 先判断是否登录，如果没登录则报错：未登录
    2. 若登录，则从 session 中清除信息即可

  3. 接口设计：

    BaseResponse<Boolean> userLogout(HttpServletRequest request)

    1. requesr是否为空，为空则报异常：参数错误
    2. 调用服务
    3. 返回

功能开发 | 用户权限控制 | 自定义注解+AOP

  1. 权限校验注解

    首先编写权限校验注解，放到 annotation 包下：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    @Target(ElementType.METHOD)
    @Retention(RetentionPolicy.RUNTIME)
    public @interface AuthCheck {

        /**
         * 必须有某个角色
         */
        String mustRole() default "";
    }

  2. 权限校验切面

    编写权限校验 AOP，采用环绕通知，在 **打上该注解的方法 **执行前后进行一些额外的操作，比如校验权限。

    校验逻辑：

    1. 从session中获取当前用户信息
    2. 如果没有则报错：用户未登录
    3. 取得注解要求的用户权限
    4. 权限校验，不满足权限则报错：权限不足
    5. 满足则放行。

    代码如下，放到 aop 包下：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    @Aspect
    @Component
    public class AuthInterceptor {
        @Resource
        private UserService userService;

        @Around("@annotation(authCheck)")
        public Object authInterceptor(ProceedingJoinPoint joinPoint, AuthCheck authCheck) throws Throwable {
            //1. 从session中获取当前用户信息
            RequestAttributes requestAttributes = RequestContextHolder.currentRequestAttributes();
            HttpServletRequest request = ((ServletRequestAttributes) requestAttributes).getRequest();
            //2. 如果没有则报错：用户未登录
            Object attribute = request.getSession().getAttribute(UserConstant.USER_LOGIN_STATE);
            LoginUserVO user=(LoginUserVO) attribute;
            ThrowUtils.throwIf(user==null, ErrorCode.NOT_LOGIN_ERROR,"该操作需要用户登录");
            //3. 取得注解要求的用户权限
            String mustRole = authCheck.mustRole();
            UserRoleEnum mustRoleEnum = UserRoleEnum.getEnumByValue(mustRole);
            UserRoleEnum userRoleEnum = UserRoleEnum.getEnumByValue(user.getUserRole());
            //4. 权限校验，不满足权限则报错：权限不足
            if(mustRoleEnum==null){
                // 不需要权限,直接放行
                return joinPoint.proceed();
            }
            ThrowUtils.throwIf(userRoleEnum==null,ErrorCode.NO_AUTH_ERROR,"该操作需要用户登录");
            ThrowUtils.throwIf(mustRoleEnum.equals(UserRoleEnum.ADMIN)&&!mustRoleEnum.equals(userRoleEnum),ErrorCode.NO_AUTH_ERROR,"该操作需要管理员");
            //5. 满足则放行
            Object proceed = joinPoint.proceed();
            return proceed;
        }
    }

    这段代码中有几个点需要记录：

    • @Around("@annotation(authCheck)")：@Around 表示这是一个环绕通知，里面是切点表达式的一种写法，用于匹配有指定注解的方法（注解作用在方法上面）

    • ```java
      RequestAttributes requestAttributes = RequestContextHolder.currentRequestAttributes();
      HttpServletRequest request = ((ServletRequestAttributes) requestAttributes).getRequest();

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38

           这是一种在非 controller 中直接获取 HttpServletRequest 对象的一种方法。

         - `Object ret=joinPoint.proceed();`：调用目标方法，实际执行了被拦截的方法，并获取了它的返回值。

         - `return ret`：返回值给目标方法的调用方。

         - 如果在aop中修改目标方法的参数，则必须在调用 proceed() 时带上修改后的参数，否则传入的参数还是没被修改的参数。

           示例：
           
           1. `Object[] args=joinPoint.getArgs()`获取参数
           2. 对参数进行修改
           3. `Object ret=joinPoint.proceed(args);`传入修改后的参数并执行目标方法。

      3. 使用注解

         只要给方法添加了 @AuthCheck 注解并限定权限，就能进行校验。



      ### 功能开发 | 用户管理

      管理员相关的功能包括：

      - 【管理员】创建用户
      - 【管理员】根据 id 删除用户
      - 【管理员】更新用户
      - 【管理员】分页获取用户列表（需要脱敏）
      - 【管理员】根据 id 获取用户（未脱敏）
      - 根据 id 获取用户（脱敏）



      1. 数据模型

         `dto/user`目录：

      ├─dto
      │ └─user
      │ UserAddRequest.java

    │ UserLoginRequest.java
    │ UserQueryRequest.java
    │ UserRegisterRequest.java
    │ UserUpdateRequest.java

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47

    2. 接口开发

       这一段是最常见的增删检查开发，就不介绍代码，只记录一些要点：

       1. Mybatis-plus3.5.9及之后的版本都不再内置分页插件依赖，如果需要，则专门引入分页插件依赖。
       2. 这些增删改查的代码直接写在了 controller 层，因为逻辑简单且代码量较小，可以灵活设计，不用特意在 service 中写方法。



    ### 功能开发 | 数据精度修复 | 全局JSON配置

    1. 后端接口返回的数据普遍由 Spring 自动序列化为 JSON格式数据，并返回给前端。

    2. 而存在一些情况，默认的序列化不满足我们的需求：

       以当前返回的 `UserVO` 为例，字段`id`的类型是`Long`，这样的数据前端本来可以接收并自动转为字符串，但是如果数据精度过高，而前端 JS 的精度范围有限，就会造成数据失真——数据的高精度被自动置为0。

    3. 所以需要自定义全局 JSON 序列化配置，为特定情况指定规则：

       Jackson 是 Spring Web 内置的一个可以处理 JSON 数据的框架。

       以解决上述精度丢失问题为例使用 Jackson：

       1. 在后端 `config` 包下新建一个全局 JSON 配置，使用 Jackson 将整个后端接口返回值的长整型数字转换为字符串进行返回

          ```java
          @Configuration
          public class JsonConfig {
          
              /**
               * 创建Jackson对象映射器
               *
               * @param builder Jackson对象映射器构建器
               * @return ObjectMapper
               */
              @Bean
              public ObjectMapper jacksonObjectMapper(Jackson2ObjectMapperBuilder builder) {
                  ObjectMapper objectMapper = builder.createXmlMapper(false).build();
                  SimpleModule module = new SimpleModule();
                  // 配置对象序列化，将所有Long对象转成String，以解决精度丢失问题。
                  module.addSerializer(Long.class, ToStringSerializer.instance);
                  module.addSerializer(Long.TYPE, ToStringSerializer.instance);
                  objectMapper.registerModule(module);
                  return objectMapper;
              }
          }

    1. 通过这样的方式我们还可以配置其他的情况，例如日期格式处理：

      1
      2
      //日期格式处理
      objectMapper.setDateFormat(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));

后端开发 | 图片模块

需求分析

在设计图库系统时，要优先确保用户能够查看图片功能的实现，而上传功能暂时仅限管理员使用，以保证系统的安全性和稳定性。

基于这一原则，我们将优先实现以下功能，并按优先级排列如下：

1）管理员功能

  • 图片上传与创建
  • 图片管理
  • 图片修改（编辑信息）

2）用户功能

  • 查看与搜索图片列表（主页）
  • 查看图片详情（详情页）
  • 图片下载

具体分析每个需求：

1）图片上传与创建：仅管理员可用，支持选择本地图片上传，并填写相关信息，如名称、简介、标签、分类等。系统会自动解析图片的基础信息（如宽高和格式等），便于检索。

2）图片管理：管理员可以对图库内的图片资源进行管理，包括查询和删除。

3）图片修改：管理员可以对图片信息进行编辑，例如修改名称、简介、标签、分类等。

4）查看与搜索图片列表：用户在主页上可按关键词搜索图片，并支持按分类、标签等筛选条件分页查看图片列表。

5）查看图片详情：用户点击列表中的图片后，可进入详情页，查看图片的大图及相关信息，如名称、简介、分类、标签、其他图片信息（如宽高和格式等）。

6）图片下载：用户在详情页可点击下载图片按钮，将图片保存至本地。

创建图片的业务流程分析：

创建图片其实包括了 2 个过程：上传图片文件 + 补充图片信息并保存到数据库中

有 2 种常见的处理方式：

  • 先上传再提交数据：用户直接上传图片，系统生成图片的存储 URL；然后在用户填写其他相关信息并提交后，才保存图片记录到数据库中。

  • 上传图片时直接保存记录：在用户上传图片后，系统立即生成图片的完整数据记录（包括图片 URL 和其他元信息），无需等待用户点击提交，图片信息就立刻存入了数据库中。之后用户再填写其他图片信息，相当于编辑了已有图片记录的信息。

方案 1 的优点是流程简单，但缺点是如果用户不提交，图片会残留在存储中，导致空间浪费；方案 2 则可以理解为保存了 “图片草稿”，即使用户不填写任何额外信息，也能找到之前的创建记录。

该项目选择第二种。

如何解析图片的信息？

通过第三方云存储服务（如腾讯云 COS、AWS S3）或图像处理 API（如 ImageMagick、ExifTool）直接提取图片的元数据。

这样一来，我们不用再单独引入一个库或者自己编写解析代码了，更方便；而且提供的免费额度足够用了，所以采用这种方式。

数据库设计

图片表 picture

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
-- 图片表  
create table if not exists picture  
(  
    id           bigint auto_increment comment 'id' primary key,  
    url          varchar(512)                       not null comment '图片 url',  
    name         varchar(128)                       not null comment '图片名称',  
    introduction varchar(512)                       null comment '简介',  
    category     varchar(64)                        null comment '分类',  
    tags         varchar(512)                      null comment '标签（JSON 数组）',  
    picSize      bigint                             null comment '图片体积',  
    picWidth     int                                null comment '图片宽度',  
    picHeight    int                                null comment '图片高度',  
    picScale     double                             null comment '图片宽高比例',  
    picFormat    varchar(32)                        null comment '图片格式',  
    userId       bigint                             not null comment '创建用户 id',  
    createTime   datetime default CURRENT_TIMESTAMP not null comment '创建时间',  
    editTime     datetime default CURRENT_TIMESTAMP not null comment '编辑时间',  
    updateTime   datetime default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '更新时间',  
    isDelete     tinyint  default 0                 not null comment '是否删除',  
    INDEX idx_name (name),                 -- 提升基于图片名称的查询性能  
    INDEX idx_introduction (introduction), -- 用于模糊搜索图片简介  
    INDEX idx_category (category),         -- 提升基于分类的查询性能  
    INDEX idx_tags (tags),                 -- 提升基于标签的查询性能  
    INDEX idx_userId (userId)              -- 提升基于用户 ID 的查询性能  
) comment '图片' collate = utf8mb4_unicode_ci;

字段设计方法：设计字段时也像这样分类思考，先设计基础信息，再针对图片属性设计字段

  • 基础信息：包括图片的 URL、名称、简介、分类、标签等，满足图片管理和分类筛选的基本需求。
  • 图片属性：记录图片大小、分辨率（宽度、高度）、宽高比和格式，方便后续按照多种维度筛选图片。
  • 用户关联：通过 userId 字段关联用户表，表示由哪个用户创建了该图片。

添加索引，优化查询性能

为高频查询的字段（如图片名称、简介、分类、标签、用户 id）添加索引，提高查询效率

技术选型 | 对象存储

如何存储用户上传的图像？

对象存储是一种存储 海量文件 的 分布式 存储服务，具有高扩展性、低成本、可靠安全等优点。

推荐直接使用第三方提供的对象存储服务。这里选择COS。

功能开发 | 后端操作COS

  1. 引入 COS 依赖

  2. 在application.yml中进行配置：

    • 新建配置文件application-local.yml，在其中配置 COS 的信息
    • 在application.yml中配置使用新配置文件

  3. 新建 CosClientConfig 类。读取配置文件，并创建一个COSClient的 Bean。

  4. 新建 CosManager 类，在这里编写通用的对象存储方法，比如对象上传、对象下载等

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    @Component
    public class CosManager {

      @Resource
      private CosClientConfig cosClientConfig;

      @Resource
      private COSClient cosClient;

      /**
         * 上传对象
         *
         * @param key  唯一键
         * @param file 文件
         */
      public PutObjectResult putObject(String key, File file) {
        PutObjectRequest putObjectRequest = new PutObjectRequest(cosClientConfig.getBucket(), key,
                                                                 file);
        return cosClient.putObject(putObjectRequest);
      }


      /**
         * 下载对象到后端服务器
         *
         * @param key
         * @param file
         * @return
         */
      public ObjectMetadata getObject(String key,File file){
        GetObjectRequest getObjectRequest = new GetObjectRequest(cosClientConfig.getBucket(), key);
        return cosClient.getObject(getObjectRequest, file);
      }

      /**
         * 下载对象用来返回给前端，流式下载
         *
         * @param key 唯一键
         */
      public COSObject getObject(String key) {
        GetObjectRequest getObjectRequest = new GetObjectRequest(cosClientConfig.getBucket(), key);
        return cosClient.getObject(getObjectRequest);
      }
    }

功能开发 | COS文件下载

官方文档介绍了 2 种文件下载方式。一种是直接下载 COS 的文件到后端服务器；另一种是获取到文件下载输入流（适合返回给前端用户）。

下面直接贴出代码：

第一种：直接下载到后端服务器：

CosManager 封装下载对象的方法getObject()：

1
2
3
4
5
6
7
8
9
10
11
/**
     * 下载对象到后端服务器
     * 
     * @param key
     * @param localFile
     * @return
     */
    public ObjectMetadata getObject(String key,File localFile){
        GetObjectRequest getObjectRequest = new GetObjectRequest(cosClientConfig.getBucket(), key);
        return cosClient.getObject(getObjectRequest, localFile);
    }

在 FileController 中编写测试文件下载接口。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/**
     * 测试文件下载
     *
     * @param key
     * @return
     */
@AuthCheck(mustRole = UserConstant.ADMIN_ROLE)
@GetMapping("/test/download")
public BaseResponse<Boolean> testDownloadFile(@RequestParam String key) {
  key=String.format("/%s/%s", FileConstant.UPLOAD_PATH_PREFIX,key);
  try {
    File localFile = new File(String.format("%s/%s",FileConstant.DOWNLOAD_PATH_PREFIX,key));
    ObjectMetadata objectMetadata = cosManager.getObject(key,localFile);
  } catch (CosServiceException e) {
    e.printStackTrace();
  } catch (CosClientException e) {
    e.printStackTrace();
  }
  return ResultUtils.success(true);
}

第二种：获取到文件下载输入流，并写入到响应中

CosManager 封装下载对象的方法getObject()：

1
2
3
4
5
6
7
8
9
/**  
 * 下载对象（适合返回给前端用户）
 *  
 * @param key 唯一键  
 */  
public COSObject getObject(String key) {  
    GetObjectRequest getObjectRequest = new GetObjectRequest(cosClientConfig.getBucket(), key);  
    return cosClient.getObject(getObjectRequest);  
}

在 FileController 中编写测试文件下载接口。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
/**
     * 测试文件流式下载
     *
     * @param filepath 文件路径
     * @param response 响应对象
     */
@AuthCheck(mustRole = UserConstant.ADMIN_ROLE)
@GetMapping("/test/download/")
public void testDownloadFile(String filepath, HttpServletResponse response) throws IOException {
  COSObjectInputStream cosObjectInput = null;
  try {
    COSObject cosObject = cosManager.getObject(filepath);
    cosObjectInput = cosObject.getObjectContent();
    // 处理下载到的流
    byte[] bytes = IOUtils.toByteArray(cosObjectInput);
    // 设置响应头
    response.setContentType("application/octet-stream;charset=UTF-8");
    response.setHeader("Content-Disposition", "attachment; filename=" + filepath);
    // 写入响应
    response.getOutputStream().write(bytes);
    response.getOutputStream().flush();
  } catch (Exception e) {
    log.error("file download error, filepath = " + filepath, e);
    throw new BusinessException(ErrorCode.SYSTEM_ERROR, "下载失败");
  } finally {
    if (cosObjectInput != null) {
      cosObjectInput.close();
    }
  }
}

功能开发 | 图片上传

功能概述：在用户上传图片后，系统立即生成图片的完整数据记录（包括图片 URL 和其他元信息），无需等待用户点击提交，图片信息就立刻存入了数据库中。之后用户再填写其他图片信息，相当于编辑了已有图片记录的信息。

下面的开发过程属于自底向上，将整个图片上传业务逐级分层，各层级之间的划分明确。

数据模型

在model/dto/picture下新建PictureUploadRequest。

在model/VO下新建PictureVO。，与Picture的主要区别是关联了上传用户的信息User，只有管理员能得到PictureVO

在model/file下新建UploadPictureResult，用于封装COS返回的图片解析信息。

通用图片上传服务

目前封装的putObject()方法只是单纯的把图片上传到COS，但是我们的业务需要得到图片的解析信息。

我们需要使用COS的数据万象服务，支持我们上传图片的同时，返回图片的解析信息。

  1. 开通数据万象服务。
  2. 在CosManager中封装putPictureObject()方法，进行上传图片，并返回图片解析信息。

图片上传服务开发

  1. 新建FileManager类，在这里进行编写图片本身的各类校验，校验通过后，调用通用图片上传服务：
    1. 校验图片的大小、格式。
    2. 校验通过后，构建图片的上传路径。
    3. 上传文件并得到COS返回的图片解析信息。
    4. 将COS的图片解析信息封装到自定义的UploadPictureResult类并返回
  2. 新建PictureService服务层，在这里编写最贴近业务的逻辑：
    1. 校验此次上传是新增图片还是更新图片。
    2. 如果是更新图片，则要校验原图片是否存在。
    3. 无论是新增还是更新，都要上传图片，调用FileManager的图片上传方法。
    4. 每个图片在存储空间的前缀格式均为public/{上传用户ID}，这要作为参数传给FileManager。
    5. 上传成功并得到返回信息后，更新数据库的图片信息。

图片上传接口

新建PictureController接口层，在这里校验用户的登录态以及权限，以及进行基本的参数判空校验。

性能优化

目前，后端接收到上传的图片后，会在本地创建一个临时文件，再将这个文件上传给COS。但实际上我们的业务不需要对这个文件做什么修改，所以完全可以用流的方式将文件直接上传，提高性能。

功能开发 | 图片管理

  • 【管理员】根据 id 删除图片
  • 【管理员】更新图片（update）
  • 【管理员】获取图片列表（分页）
  • 【管理员】根据 id 获取图片
  • 【用户】 编辑图片（edit）
  • 【用户】根据 id 获取图片
  • 【用户】获取图片列表（分页）

数据模型

在model/dto/picture下新建：

  • PictureUpdateRequest
  • PictureQueryRequest extends PageRequest
  • PictureEditRequest

在model/VO下新建PictureVO。，与Picture的唯一区别是关联了上传用户的信息User

服务开发

即图片的增删改查。不写具体代码了，只记录知识点。

  • HuTools的工具类：ObjUtil、StrUtil、CollUtil，常用方法：isNotNull()

  • QueryWrapper的or语法使用：

    queryWrapper.and(qw -> qw.like("name",searchText).or().like("introduction",searchText));

  • QueryWrapper的返回结果按指定字段排序：

    queryWrapper.orderBy(StrUtil.isNotEmpty(sortField), sortOrder.equals("ascend"), sortField);

  • 一段骚代码：

    这里我们做了个小优化，不是针对每条数据都查询一次用户，而是先获取到要查询的用户 id 列表，只发送一次查询用户表的请求，再将查到的值设置到图片对象中。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /**
         * 分页获取图片封装
         */
    @Override
    public Page<PictureVO> getPictureVOPage(Page<Picture> picturePage) {
      List<Picture> pictureList = picturePage.getRecords();
      Page<PictureVO> pictureVOPage=new Page<>(picturePage.getCurrent(),picturePage.getSize(),picturePage.getTotal());
      if(pictureList==null){
        return pictureVOPage;
      }
      List<PictureVO> pictureVOList=pictureList.stream().map(PictureVO::objToVo).collect(Collectors.toList());
      Set<Long> userIdSet=pictureVOList.stream().map(PictureVO::getId).collect(Collectors.toSet());
      Map<Long,List<User>> map=userService.listByIds(userIdSet).stream().collect(Collectors.groupingBy(User::getId));
      pictureVOList.forEach(pictureVO -> {
        User user = map.get(pictureVO.getUserId()).get(0);
        UserVO userVO = userService.getUserVO(user);
        pictureVO.setUser(userVO);
      });
      pictureVOPage.setRecords(pictureVOList);
      return pictureVOPage;
    }

功能开发 | 用户传图、管理审核

需求分析

之前我们已经开发了管理员上传图片功能，想实现用户上传图片就比较简单了，但是我们要考虑到一点 “用户上传的内容可能是不安全的”。

一般只要涉及到 “用户上传内容”（俗称 UGC）的场景，就要增加审核功能。

具体分析每个需求：

1）用户上传创建图片：需要开放权限，允许用户上传图片，功能和流程跟之前管理员上传图片一致，也要增加文件校验。

2）管理员审核图片：管理员可以查看和 筛选 所有待审核的图片，并标记为通过或拒绝，可填写通过或拒绝的具体原因。此外，需要记录审核人和审核时间作为日志，如果发现误审的情况也可以追责。

方案设计

1. 审核逻辑

1）管理员可以操作审核的状态流转：

  • 默认为 “待审核”，可以设置为 “审核通过” 或 “审核拒绝”
  • 已拒绝的图片可以重新审核为通过
  • 已通过的图片可以撤销为拒绝状态

2）管理员自动审核：管理员上传 / 更新图片时，图片自动审核通过，并且自动填充审核参数 —— 设置审核人为创建人、审核时间为当前时间、审核原因为 “管理员自动过审”。
3）用户操作需要审核：用户上传或编辑图片时，图片的状态会被重置为“待审核”。
重复审核时，既可以选择重置 所有 审核参数，也可以仅重置审核状态。其余参数在前端不展示，但是在后端保留，以便管理员参考历史审核信息。
4）控制内容可见性：对于用户来说，应该只能看见 “审核通过” 状态的数据；管理员可以在图片管理页面看到所有数据，并且根据审核状态筛选图片。
Q：是否要考虑并发问题呢？
A：由于审核操作为管理员手动执行，不涉及复杂的奖励机制或并发高频请求，误审核或重复审核对系统影响不大，因此无需过度考虑并发问题。

数据模型

Picture新增字段:

  • reviewStatus
  • reviewMessage
  • reviewId
  • reviewTime

PictureQueryRequest新增字段：

  • reviewStatus
  • reviewMessage
  • reviewId

新建PictureReviewRequest：

  • id
  • reviewStatus
  • reviewMessage

功能开发 | 通过URL上传图片

步骤：

  1. 下载图片：从远程 url 下载图片，临时保存到本地，这可以使用 Hutool 的HttpUtil.downloadFile()一行代码解决。

  2. 校验图片：

    传统的校验思路是先把文件下载到本地，再对本地文件进行校验，有没有更节省资源的方法呢？

    其实可以先对 URL 本身进行校验。首先是校验 URL 字符串本身的合法性，比如要是一个合理的 URL 地址。此外，可以先使用 HEAD 请求来获取 URL 对应文件的元信息（如文件大小、格式等）。HEAD 请求仅返回 HTTP 响应头信息，而不会下载文件的内容，大大降低了网络流量的消耗。

  3. 上传图片。

通过 URL 校验图片信息

  1. 验证是合法的URL：

    new URL(fileURL)，如果是合法的就不会抛异常

  2. 校验URL协议：

    fileUrl.startsWith("http://") || fileUrl.startsWith("https://")

  3. 发送head请求验证文件是否存在：这里注意，有些URL地址不支持通过HEAD请求访问，为了提高导入率，即使访问失败，也不报错。只对能获取到的信息进行校验。

    1
    2
    3
    4
    5
    HttpResponse response=null;
    response=HttpUtil.createRequest(Method.HEAD,fileUrl).execute();
    if(response.getStatus()!=HttpStatus.HTTP_OK){
      return;
    }

  4. 校验文件类型

    1
    2
    3
    4
    5
    6
    7
    String contentType=response.header("Content-Type");
    if(StrUtil.iSNotBlank(contentType)){
      final List ALLOW_FILE_TYPE_SUFFIX=Arrays.asList("image/jpg","image/png","image/webp","image/jpeg");
      if(!ALLOW_FILE_TYPE_SUFFIX.contains(contentType.toLowerCase())){
        抛异常
      }
    }

  5. 校验文件大小

    1
    String contentLengthStr=response.header("Content-Length")

  6. 最后关闭流response.close()

代码优化：模版方法设计模式（简历优势点）

我们现在有两种图片上传方式：本地图片上传和URL图片上传——但是实际上，这两种方式的逻辑流程基本一致：

  1. 校验图片
  2. 获取源文件名
  3. 构造上传路径
  4. 创建临时文件
  5. 文件上传
  6. 接收COS图片解析信息，封装解析信息返回类
  7. 删除文件

可以将一致的流程封装成模板类，流程中不同的实现定义为方法，让实现类继承模版类，并实现方法，这就是模版方法设计模式

模版类manager/upload/PictureUploadTemplate代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
/**
 * @author Michael
 */
@Slf4j
public abstract class PictureUploadTemplate {
  @Resource
  private CosClientConfig cosClientConfig;
  @Resource
  private CosManager cosManager;

  public final UploadPictureResult uploadPicture(Object inputObject,String uploadPathPrefix){
    //1. 校验图片
    validPicture(inputObject);
    //2. 获取源文件名
    String originalFilename=getOriginalFilename(inputObject);
    //3. 构造上传路径
    String uuid = RandomUtil.randomString(16);
    String uploadFilename = String.format("%s_%s.%s", DateUtil.formatDate(new Date()), uuid,
                                          FileUtil.getSuffix(originalFilename));
    String uploadPath=String.format("/%s/%s", uploadPathPrefix, uploadFilename);
    File file=null;
    try {
      file=File.createTempFile(uploadPath,null);
      //4. 创建临时文件
      file= processFile(inputObject,file);
      //5. 操作COS客户端上传文件
      PutObjectResult putObjectResult = cosManager.putPictureObject(uploadPath, file);
      //6. 获取COS返回的图片解析信息
      UploadPictureResult uploadPictureResult= buildResult(putObjectResult, originalFilename, file, uploadPath);
      return uploadPictureResult;
    } catch (Exception e) {
      log.error("图片上传到对象存储失败", e);
      throw new BusinessException(ErrorCode.SYSTEM_ERROR, "上传失败");
    }finally {
      //7. 删除临时文件
      if (file != null) {
        boolean deleteResult = file.delete();
        if (!deleteResult) {
          log.error("file delete error, filepath = {}", file.getAbsolutePath());
        }
      }
    }
  }

  /**
     * 校验图片
     * @param inputObject
     */
  public abstract void validPicture(Object inputObject);

  /**
     * 获取源文件名
     * @param inputObject
     * @return
     */
  public abstract String getOriginalFilename(Object inputObject);

  /**
     * 创建临时文件
     * @param inputObject
     * @param file
     * @return
     */
  public abstract File processFile(Object inputObject, File file) throws IOException;

  /**
     * 封装图片解析信息
     * @param putObjectResult
     * @return
     */
  public UploadPictureResult buildResult(PutObjectResult putObjectResult,String originalFilename,File file,String uploadPath){
    UploadPictureResult uploadPictureResult = new UploadPictureResult();
    ImageInfo imageInfo = putObjectResult.getCiUploadResult().getOriginalInfo().getImageInfo();
    int picWidth = imageInfo.getWidth();
    int picHeight = imageInfo.getHeight();
    double picScale = NumberUtil.round(picWidth * 1.0 / picHeight, 2).doubleValue();
    uploadPictureResult.setPicName(originalFilename);
    uploadPictureResult.setPicWidth(picWidth);
    uploadPictureResult.setPicHeight(picHeight);
    uploadPictureResult.setPicScale(picScale);
    uploadPictureResult.setPicFormat(imageInfo.getFormat());
    uploadPictureResult.setPicSize(FileUtil.size(file));
    uploadPictureResult.setUrl(cosClientConfig.getHost() + "/" + uploadPath);
    return uploadPictureResult;
  }
}

对服务层和接口层的代码也进行对应的修改，可以PictureUploadRequest中填充参数来判断是哪种上传方式。

功能开发 | 大批量抓取和上传图片（简历优势点）

从bing的图片官网上抓取图片，抓取的方式有两种：

  1. 请求到完整页面内容后，对页面的HTML结构进行解析，提取到图片的url，再根据url下载图片。
  2. 直接调用后端获取图片的接口，获取图片数据

第二种调用接口获得仍是HTML格式的内容，需要使用一个HTML 文档解析库来提取图片地址，Java 中比较推荐 Jsoup，非常地轻量。

jsoup 支持使用跟前端一致的选择器语法来定位 HTML 的元素，比如类选择器、CSS 选择器。我们可以先通过类选择器找到最外层的元素 dgControl，再通过 CSS 选择器 img.mimg 找到所有的图片元素。

1
2
3
4
5
6
<!-- HTML 解析：https://jsoup.org/ -->  
<dependency>  
    <groupId>org.jsoup</groupId>  
    <artifactId>jsoup</artifactId>  
    <version>1.15.3</version>  
</dependency>

在抓取时可以带上关键字和抓取数量（不超过30），支持管理员每次填写抓取的偏移量，防止重复抓取。

为批量上传图片定义命令规则，否则图片name根据URL确定，过于混乱。

如何拿到后端接口

在页面向下滚动，就会触发一波新的图片加载，在控制台就能看到后端接口地址：

https://cn.bing.com/images/async?q=%s&mmasync=1

%s指的是关键字的位置

如何用Jsoup来调用接口、解析HTML内容、拿到图片URL

  1. 调用接口，获取HTML结构内容。
  2. 定位dgControl元素。
  3. 根据dgControl元素找到img.mimg，获取到img列表。
  4. 遍历img元素，获取img的URL路径。
  5. 处理URL路径字符串，避免出现转义问题。
  6. 单个图片抓取失败时并不报异常。
  7. 达到抓取数量后停止遍历。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
//1. 调用接口，获取HTML结构内容
String fatchUrl=String.format("https://cn.bing.com/images/async?q=%s&mmasync=1",searchText);
Document document=Jsoup.connect(fatchUrl).get();

//2. 定位`dgControl`元素
Element div=document.getElementsbyClass("dgControl").first();

//3. 根据`dgControl`元素找到`img.mimg`，获取到`img`列表
Elements imgElementList=div.select("img.mimg");

//4. 遍历`img`元素，`img`的URL路径获取：
String fileUrl=element.attr("src");

//5. 处理URL路径字符串，避免出现转义问题
int questionMarkIndex=fileUrl.indexOf("?");
if(questionMarkIndex > -1){
  fileUrl=fileUrl.subString(0,questionMarkIndex);
}

优化

抓取更清晰的图片。

后端开发 | 图片模块优化

图片优化技术：

  • 图片查询优化
  • 图片上传优化
  • 图片加载优化
  • 图片存储优化

图片查询优化

对于listPicturePage接口使用 Redis 进行缓存

Redis 分布式缓存

1
2
3
4
5
<!-- Redis -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

Redis缓存设计三要素：key、value、timeout

1）缓存key设计

注意，由于图片查询支持不同的参数查询，所以key中也要包含查询参数。

可以将查询条件对象转换成 JSON 字符串，然后通过MD5算法压缩并控制长度。

1
michael:picture:listPicturePage:${查询条件}

2）缓存value设计

为了可读性，把page对象转换为 JSON 格式的字符串：

1
String cacheValue = JSONUtil.toJsonStr(picturePage);

JSON 字符串转为 Java 对象：

1
Page picturePage = JSONUtil.toBean(cachevalue,Page.class)

3）过期时间设计

5-60min。

Caffeine 本地缓存

（注意如果要引入 3.x 版本的 Caffeine，Java 版本必须 >= 11！如果不想升级 JDK，也可以改为引入 2.x 版本。）

本地缓存直接将数据缓存到应用的内存中（例如JVM），下次访问时，直接从内存读取，而不需要经过网络或其他存储系统。

本地缓存应用场景：

  • 数据量有限的小型数据集（本地缓存不易扩容）。
  • 没有服务器共享数据的要求。
  • 高频、低延迟的访问场景（用户临时会话，短期热点数据）。

本地缓存不需要引入中间件，因此在没有分布式要求下，可以优先考虑本地缓存，响应速度比redis更快。

1
2
3
4
5
6
<!-- 本地缓存 Caffeine -->
<dependency>
  <groupId>com.github.ben-manes.caffeine</groupId>
  <artifactId>caffeine</artifactId>
  <version>3.1.8</version>
</dependency>

Caffeine 缓存设计

基本与Redis缓存设计一致，但是有两点不同：

  1. 本地缓存需要自己创建初始化缓存结构（可以简单理解为要自己 new 一个 HashMap）。

    1
    private final Cache<String,String> LOCAL_CACHE = Caffeine.newBuilder().initialCapacity(1024).maximumSize(10000L).expireAfterWrite(5L,TimeUnit.MINUTES).build();

  2. 由于本地缓存本身就是服务器隔离的，而且占用服务器的内存，key 可以更精简一些，不用再添加项目前缀。

拓展：这两种缓存方式同样流程一致，可以使用模版方法设计模式进行优化，保证灵活的切换。但是这里不使用，因为下面要将多级缓存。

多级缓存 | Redis + Caffeine

多级缓存是指结合本地缓存和分布式缓存的优点，在同一业务场景下构建两级缓存系统，这样可以兼顾本地缓存的高性能、以及分布式缓存的数据一致性和可靠性。多级缓存还有一个优势，就是提升了系统的容错性。即使 Redis 出现故障，本地缓存仍可提供服务，减少对数据库的直接依赖。

多级缓存工作流程：

  1. 第一级（Caffeine本地缓存），如果有则返回，否则继续。
  2. 第二级（Redis分布式缓存），如果有，则写到 Caffeine 中并返回，否则继续。
  3. 查询数据库，写到 Caffeine 和 Redis 中。

缓存常见问题解决：

  • 缓存击穿：某个数据为热点数据，该数据过期后，大量请求直接打到数据库。

    解决方式：

    • 方式一：设置超长过期时间。
    • 方式二：使用分布式锁进行缓存更新空值（如Redisson）。

  • 缓存穿透：用户频繁请求不存在的数据，导致大量请求直接打到数据库。

    解决方式：

    • 对查询无效的数据也进行缓存（如设置空值缓存）（实现）

  • 缓存雪崩：大量数据同时过期，大量请求同时打到数据库。

    解决方式：

    • 方式一：设置随机过期时间。
    • 方式二：设计多级缓存。（实现）

自动识别热点图片缓存

采用热key探测技术，实时监测图片的访问量，并自动将热点图片保存到本地缓存，以应对突发的高频访问。

后端开发 | 空间模块

为什么需要【空间】概念？

我们设想是：用户可以将网站当做自己私人的图片存储空间，上传的图片是仅自己可见、不需要被审核的，这与之前的用户上传图片逻辑有较大的冲突；

其次，用户把网站作为私人图片云盘，但是服务器存储会产生存储费用，不能放任用户无限制的上传图片，这又与之前的公共图库上传无限制有冲突；

最后，项目还可以对企业做出扩展，支持团队写作编辑图片，各个企业之间当然是隔离的，这也符合【空间】的概念。

总之，新增【空间】概念，既能最大程度减少对原有代码的修改，又能方便的扩展新功能，区分各功能之间的独立性。

数据库设计

空间表

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
-- 空间表
create table if not exists space
(
    id         bigint auto_increment comment 'id' primary key,
    spaceName  varchar(128)                       null comment '空间名称',
    spaceLevel int      default 0                 null comment '空间级别：0-普通版 1-专业版 2-旗舰版',
    maxSize    bigint   default 0                 null comment '空间图片的最大总大小',
    maxCount   bigint   default 0                 null comment '空间图片的最大数量',
    totalSize  bigint   default 0                 null comment '当前空间下图片的总大小',
    totalCount bigint   default 0                 null comment '当前空间下的图片数量',
    userId     bigint                             not null comment '创建用户 id',
    createTime datetime default CURRENT_TIMESTAMP not null comment '创建时间',
    editTime   datetime default CURRENT_TIMESTAMP not null comment '编辑时间',
    updateTime datetime default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '更新时间',
    isDelete   tinyint  default 0                 not null comment '是否删除',
    -- 索引设计
    index idx_userId (userId),        -- 提升基于用户的查询效率
    index idx_spaceName (spaceName),  -- 提升基于空间名称的查询效率
    index idx_spaceLevel (spaceLevel) -- 提升按空间级别查询的效率
) comment '空间' collate = utf8mb4_unicode_ci;

图片表新增字段 spaceId

1
2
3
4
5
6
-- 添加新列
ALTER TABLE picture
    ADD COLUMN spaceId  bigint  null comment '空间 id（为空表示公共空间）';

-- 创建索引
CREATE INDEX idx_spaceId ON picture (spaceId);

功能开发 | 空间管理

管理员增删改查再别说。

需要重点关注接口的权限：

  • 创建空间：所有用户都可以使用
  • 删除空间：仅允许空间创建人或管理员删除
  • 更新空间：仅管理员可用，允许更新空间级别
  • 编辑空间：允许空间创建人使用，但注意可编辑的字段（不能编辑空间级别）

功能开发 | 用户创建空间 | 并发处理

用户可以创建私人空间，但只能创建一个。

如何控制只能创建一个：

  • 数据库唯一索引，这个方式最简单粗暴，但由于后续用户还可以创建团队空间，这种方式不利于扩展
  • Redisson分布式锁。

最粗暴的方式是给空间表的 userId 加上唯一索引，但由于后续用户还可以创建团队空间，这种方式不利于扩展。

使用 Redisson 目前又有点多余，因为用户只能在一处登录，用户创建空间没有分布式的并发场景。

所以我们目前采用 本地加锁 + 事务 的方式实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 针对用户进行加锁
String lock = String.valueOf(userId).intern();
synchronized (lock) {
  Long newSpaceId = transactionTemplate.execute(status -> {
    boolean exists = this.lambdaQuery().eq(Space::getUserId, userId).exists();
    ThrowUtils.throwIf(exists, ErrorCode.OPERATION_ERROR, "每个用户仅能有一个私有空间");
    // 写入数据库
    boolean result = this.save(space);
    ThrowUtils.throwIf(!result, ErrorCode.OPERATION_ERROR);
    // 返回新写入的数据 id
    return space.getId();
  });
  // 返回结果是包装类，可以做一些处理
  return Optional.ofNullable(newSpaceId).orElse(-1L);
}

上述代码，我们使用本地锁synchronized对userId进行加锁，这样可以保证不同的用户拿到不同的锁，降低锁对性能的影响。

使用Spring 的 编程式事务管理器 transactionTemplate开启事务，进行空间的创建操作，而不是使用@Transactional，保证事务的范围在锁的控制之内。

扩展知识 - 本地锁优化

上述代码中，我们是对字符串常量池（intern）进行加锁的，数据并不会及时释放。如果还要使用本地锁，可以按需选用另一种方式 —— 采用 ConcurrentHashMap 来存储锁对象。

示例代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
Map<Long, Object> lockMap = new ConcurrentHashMap<>();
public long addSpace(SpaceAddRequest spaceAddRequest, User user) {
    Long userId = user.getId();
    Object lock = lockMap.computeIfAbsent(userId, key -> new Object());
    synchronized (lock) {
        try {
            // 数据库操作
        } finally {
            // 防止内存泄漏
            lockMap.remove(userId);
        }
    }
}

展开全文 >>

JS的原型与继承

在学习JS的过程中，感受到其与经典OOP语言JAVA的较大不同之处。所以写了这篇文章，记录这些不同的地方。至于一些相似的特性，则没有提及。更多了解可以在MDN查阅上相关文档。

概述

对于使用过基于类的语言 (如 Java 或 C++) 的开发者们来说，JavaScript 实在是有些令人困惑 —— JavaScript 是动态的，本身不提供一个 class 的实现。即便是在 ES2015/ES6 中引入了 class 关键字，但那也只是语法糖，我们现在确实可以通过类似于Java的方式创建和继承一个“类”，但底层仍然是基于原型的，这个“类”也只是模拟出来的，实际上底层仍是一个对象。下面当我们提到类时，不要忘记这一点。JS中一切皆对象。

在传统的OOP中，我们通过class关键字定义类，然后在里面写我们的构造函数。JS中并不如此，当我们在写Ball的构造器时，如function Ball(){}，这就已经定义好了一个Ball类，当然我们没有定义任何属性。

当我们定义好Ball的构造器function Ball(){}，通过上面的了解我们知道，这实际上就是一个对象。在JS中，任何一个对象（除了顶层对象Object，其原型为null），都会自动有一个原型对象。Ball也有一个原型对象，从意义上来说，Ball就是继承自这个原型对象。

在传统的 OOP 中，首先定义“类”，此后创建对象实例时，类中定义的所有属性和方法都被复制到实例中。在 JavaScript 中并不如此复制——而是在对象实例和它的构造器之间建立一个链接（它是__proto__属性，是从构造函数的prototype属性派生的），之后通过上溯原型链，在构造器中找到这些属性和方法。

举例

当我们这样定义一个Ball类并在JS控制台中输出他的prototype属性

1
2
function Ball(){}
console.log(Ball.prototype);

结果是这样的:

1
2
3
4
5
6
7
8
9
10
11
12
{
    constructor: ƒ Ball(),
    __proto__: {
        constructor: ƒ Object(),
        hasOwnProperty: ƒ hasOwnProperty(),
        isPrototypeOf: ƒ isPrototypeOf(),
        propertyIsEnumerable: ƒ propertyIsEnumerable(),
        toLocaleString: ƒ toLocaleString(),
        toString: ƒ toString(),
        valueOf: ƒ valueOf()
    }
}

这就是Ball的原型对象。

然后创建他的实例对象并在JS控制台中输出其_proto_属性

1
2
const aBall=new Ball();
aball.getprototypeof;//Chrome的JS控制台里，只可以通过Object.getPrototypeOf() 和 Object.setPrototypeOf() 访问器来访问_proto_

我们会看到相同的结果。Ball的prototype和aBall的的\_proto\_指向的就是同一个对象。

定义我们的类

事实上，一种极其常见的对象定义模式是，在构造器（函数体）中定义属性、在 prototype 属性上定义方法。如此，构造器只包含属性定义，而方法则分装在不同的代码块，代码更具可读性。例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 构造器及其属性定义

function Test(a,b,c,d) {
  // 属性定义
};

// 定义第一个方法

Test.prototype.x = function () { ... }

// 定义第二个方法

Test.prototype.y = function () { ... }

// 等等……

construct属性

每个实例对象都从原型中继承了一个 constructor 属性，该属性指向了用于构造此实例对象的构造函数。

例如，在控制台中尝试下面的指令：

1
2
person1.constructor
person2.constructor

都将返回 Person() 构造器，因为该构造器包含这些实例的原始定义。 你可以在 constructor 属性的末尾添加一对圆括号（括号中包含所需的参数），从而用这个构造器创建另一个对象实例。毕竟构造器是一个函数，故可以通过圆括号调用；只需在前面添加 new 关键字，便能将此函数作为构造器使用。
在控制台中输入：

1
var person3 = new person1.constructor('Karen', 'Stephenson', 26, 'female', ['playing drums', 'mountain climbing']);

现在尝试访问新建对象的属性，例如：

1
2
3
person3.name.first
person3.age
person3.bio()

正常工作。通常你不会去用这种方法创建新的实例；但如果你刚好因为某些原因没有原始构造器的引用，那么这种方法就很有用了，类似于JAVA的反射应用。

使用 Object.create 创建的对象

ECMAScript 5 中引入了一个新方法：Object.create()。可以调用这个方法来创建一个新对象。新对象的原型就是调用 create 方法时传入的第一个参数：

new一个对象时所发生的的事情

当你执行：

1
var o = new Foo();

JavaScript 实际上执行的是：

1
2
3
var o = new Object();
o.__proto__ = Foo.prototype;
Foo.call(o);

如何继承一个构造器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
//下面一段是继承某个构造器的标准流程。

function Shape(x, y, velX, velY, exists) {
    this.x = x;
    this.y = y;
    this.velX = velX;
    this.velY = velY;
    this.exists = exists;
}
// 定义Ball构造器，继承自Shape
function Ball(x, y, velX, velY, exists, color, size) {
    Shape.call(this, x, y, velX, velY, exists);
    this.color = color;
    this.size = size;
}
Ball.prototype = Object.create(Shape.prototype);
Ball.prototype.constructor = Ball;

展开全文 >>

《你一生的故事》读书随笔

[TOC]

介绍

我觉得作者的后记就很适合介绍这部小说：

我对物理学中的变分原理的喜爱催生出了这个故事。从一开始接触物理，我就觉得这些原理让人着迷。但我一直不知道应该怎么把这些定律作为故事元素写进小说里。有一天，我看了一出由保罗·林克表演的话剧，说的是主人公的妻子跟乳腺癌的搏斗。我受到启发，觉得自己也许能够用变分原理写个故事，描写一个人面对无法避免的结果时的态度。几年以后，这个想法和一个朋友有关她新出生的宝宝的故事结合在一起，组成了这篇小说的核心。对于那些喜爱物理学的读者，我应该指出：这个故事中对费尔马最少时间律的讨论略去了它在量子力学方面的内容，因为该定律的经典解释更符合小说的主旨。

关于这篇故事的主题，也许我所见过的最简洁的概括出现在冯内古特给《五号屠场》二十五周年纪念版所作的简介中：“斯蒂芬·霍金认为我们无法预知未来很有挑逗意味。但现在，预知未来对我来说小菜一碟。我知道我那些无助的、信赖他人的孩子后来怎样了，因为他们已经成人。我知道我那些老友的结局是什么，因为他们大多已经退休或去世了。我想对霍金以及所有比我年轻的人们说：耐心点。你的未来将会来到你面前，像只小狗一样躺在你脚边，无论你是什么样，它都会理解你，爱你。

变分原理

大约1696年的6月，瑞士数学家 Johann Bernoulli 在 Acta Eruditorum（第一份德语的科学期刊）上向全世界的数学家发起了一项挑战。他提出了这么一个数学问题：让一个物体从静止开始沿着一个光滑无摩擦的轨道下滑，如果要求下滑过程耗时最短，轨道应该是什么形状？

这就是著名的最速降曲线问题，它一经发出，就引来的无数学者的讨论，其中就包括那位被苹果砸到的朋友——据说他在看到这个问题后，仅花了一个晚上就利用变分法给出了答案。当然，彼时的变分法可不像如今写在教科书里人尽皆知，而是牛顿自己在研究相关物理问题时构建出变分思想，后经过一大批数学家的努力，才发展成如今重要的变分原理。

变分原理是什么？将绳子的两端固定并使其自由下垂，变分原理会告诉我们绳子的形状是什么样的；一个物体由静止自由下落时，其路线总是沿重力方向，变分原理会解释说这是因为要遵守最小作用量原则；当光由空气射入水面而到达水中一点时，变分原理会保证这是光从光源到达那一点的最快路径。

最稳定、最小。最快，变分原理总是体现出一种“最优”的结果（可能某种情况下是“最差”的）。有意思的是，物理学的大多数定律都满足变分原理这一特性，就好像一切事物，只要我们给出合适的条件，它总能沿着最适合的那条路线发展。

预知未来

如果变分原理玩狼人杀，那么他一定会第一个被刀——他完全符合我们对预言家的想象，不是吗？（doge）我们看上面提到的那束最快路径的光，我们只是规定了一个起点与终点，之后就让光出发。光对终点的情况应该一无所知对吧？对路上的一切也无从知晓，因为他还没有到达那里。他只是一无所知的前进，碰到水，发生折射，最终到达的某一点——震惊的是，当他回过头来看，发现竟没有另一条更快的路径的能够到达这里。

image-20230406133912117

当我们想要去某地的时候，我们会借助导航，看看哪条路线没有堵车，红绿灯有多少，有没有新修一条更短的路，以此我们知道了路线的全部情况，这时候我们可以保证，我们走的是一条耗时最短的路线——我们靠的是卫星导航，而光没有导航，他就像……预知了路上的全部情况，经过了一系列精密的计算，并选定了一条耗时最短的路线？

或许我们可以再诗意些：没有人告诉光它的终点在哪。光选择一条最快路线，并沿其到达终点的唯一原因是：他预先就知道自己要达到哪里，知道路上的一切细节，然后计算出了一条最快的路线，并坚定的走上他的旅程——这就是《你一生的故事》，这就是我们每个人的故事，它甚至在我们每个人之前，就已经存在。

决定论与宿命论

似乎决定论在最初进入中国时，曾被翻译为宿命论，因此我们不能只凭命名去了解这两个概念，而应该去了解这两个概念理论上的区别。

决定论和宿命论都强调必然性，不同的是，决定论是因果导向的必然性，它的基础是因果定律。而宿命论是目的导向的必然性，它不强调原因，而将其诉至某种神秘力量，这种神秘力量直接支配我们的生活。决定论最终会导向某种“宿命”，因为由因果定律，一个原因一定会导向唯一一个结果（我们暂不讨论量子力学），即目的。宿命论的形态更宽泛、更多变。

我不想过多讨论哲学知识，与我而言，简单的哲学概念，就能够解释生活的困惑。

一个人感到最无助的时候，不是面对不可逾越的困难，而是回首无法改变的过去。祖母悖论无法被打破，即使是将时间加入我们的维度，回到过去，也只是另一个时间线。我们不能像拨动磁带的指针一样操纵我们的时间，属于我们的时间，永远是向前。

因此，让我们感到后悔的过去，就成为了真正无法战胜的敌人。他永远面向你，可却又永远在你身后。

我曾无数次在深夜黯然神伤，寂静的黑夜好像夺走了我向前行走的能力，让我只能身陷于当前，不断回首过往的悔恨。我不知道如何面对这个无法战胜的敌人。那时，每一个新的一天，不是活力剂，反倒更像麻醉剂，让我陷在新的忙碌之中麻痹神经，直到夜里又再度失效。

直到某一天，决定论与宿命论，如同尼采描述的正午降临的阳光、雷鸣轰下的雨点般，带给了我超人般的启迪。

阿拉，不好意思，笔到情深处有些飘逸了，我们收敛一些。

决定论强调因果联系，环环相扣，假设我们有足够的能力，我们就能够解释现在，甚至能够预知未来。宿命论则似乎有某种超脱自然的力量，我们不一定能够预知未来，但未来一定提前存在，我们永远只能按照未来的剧本前进，这类似与我们常规意义下的“命运”。

与我而言，我用决定论去释怀对过去的悔恨，用宿命论去得到前进的动力。

决定论于我

对我来说，我更关注决定论“解释现在”的能力。

：我的现在是什么样的？
：是开朗的、更加专注的。
：曾有过一段阴暗的时期吗？
：是的。
：什么让你走了出来？
：一些哲学概念。
：为什么会学这些概念？
：阴暗让我痛苦，我希望解救自己。我没有天生知晓一切的聪明，但我有变得知道一些的聪明。
：为什么会走入那段阴暗的时期？
：人总会遇到困难的。
：再往前没有过这种困难吗？
：恐怕没有，我的高中生活很开心。
：……
：……

一问一答，环环相扣，照这样的思路我们可以无止境的向前追溯，这就是决定论“解释现在”的能力。

当我们悔叹过去时，往往伴随着感慨：“如果过去……，那么今天会更好”。寸光寸金，时间永远在流逝这一点似乎给了我们巨大的压力，悔恨的过去仿佛意味着浪费的时间、挥霍的金子，葬送着未来——可是，下面的句式是否也能够成立呢：“如果没有今天……那么未来的那天将糟糕透顶”。

人的生命，没有一天是无意义的。人某一瞬的美好或悲伤，都源于所有的过去。

生活是一条连续的函数曲线，因果关系保证其可导。你结束高考的那一天、你参加工作的那一天、你走上婚礼的那一天、你失业那一天、你分手的那一天——你任何一个存在的瞬间，甚至你被车撞飞而结束生命的那一个瞬间，因果定律是适用于我们所有人生活的一阶导数，保证我们的生活连续且可导。

但我们无法掌握这种变化。你认为自己在向极大点前进，却不知自己已经在极大处，下一秒就是下降；你认为自己已经身处极小点，却不知向进竟是更低；你认为自己已经身陷谷底持久而不能动弹，却不知接下来就是上升。

如果把你悔恨的过去置换成你期盼的过去，那么你期盼的未来或许也将被置换成你悔恨的未来，现在的你也将不复存在，而是被替换成一个更开心、更成功、却也更脆弱的你，他将以更少的底气，去面对未知的未来。

没有人知道自己的命运，一切欣喜与难过都如同风中残烛。

一切欣喜与难过都如同风中残烛——所以我们应该做一个没有感情的机器吗？不是，我因情感而存在。如果情感在未测的未来前显得无力，那么请将角度调向已测的过去。

如果你觉得现在比过去更好，那么就请欣喜吧；如果你觉得现在比过去更糟，那么就请难过吧。请思考对你而言“更好”与“更糟”的评判准则；请在“更好”的时候，不要忘记曾经的“更糟”；请在“更糟”的时候，不要忘记：时间一直在向前。

于是，我们知道了什么呢？现在的我一扫阴霾，虽不像高中那般无忧，却有了更多面对困难的经历与底气。如果我没有遇到那段阴暗的时期，而是持续开心，那似乎也很美好，但却少了这份经历与底气，也面临着更多来自未来的风险。我为我当前经历的一切的感到高兴，因为我的准则是：我知道了更多，也知道了更多的不知道；我经历过悲伤，也同样经历过美好；我对未来有了更多底气，这不是因为我曾成功，而是因为我曾失败，如果没有这些失败，我将得到一些，并失去一些。如果哪天我的确再度陷入阴暗，我将会难过，但我永远不会忘记的是：时间一直在向前。

宿命论于我

正如前面所说，宿命论诉至的是超脱自然的力量，所有人无能为力。

为什么这种根本无法认识的力量能带给我动力前进？读者（如果有，呜呜）可能早就奇怪，文章写到了这里都没有涉及《你一生的故事》的任何情节，哈，实在抱歉，毕竟是笔者的自娱自乐，见谅🙏。

前面我提到，当我们觉得，现在真的比过去“更糟”时，不要忘记：时间一直在向前。我当时的意思是，“更好”的时刻会后面等着我们。这有点像我们从小听到大的鸡汤了：先苦后甜。这对吗？至少是符合普世的价值观的；这好用吗？分情况。

当人真正置身于绝望时，其实就已经与希望断绝联系了。当人真正置身于宇宙时，其实一切都没有意义了。帕斯卡（就是那个Pa斯卡）叙述了这样一种渺小：

我看到整个宇宙的可怖的空间包围了我，我发现自己被附着在那个广漠无垠的领域的一角，而我又不知道，我何以被安置在这一点而不是另一点，也不知道为何使我得以生存的这一点时间，要把我固定在这一点上，而不是先我而往的全部永恒，与继我而来的全部永恒的另一点上，我看见的只是各个方面的无穷，他把我包围的像个原子。我所明了的一切，就是我很快就会死亡，然后我所最无知的，就是这种我所无法逃避的死亡本身。

R

“江畔何人初见月，江月何年初照人”。在星空的俯视下，宇宙的无限反衬出人类的渺小。无意义，这是在最为宏大的视角下，唯一存在的结果。此时，人唯有依靠信仰，才能在无意义的宇宙中追求意义，从而在这个过程中成为意义本身。这里的信仰涉及但不是宗教意义上的信仰，我想表达的是丹麦哲学家克尔凯廓尔的所谓“信仰”，具体可以参考我另一篇文章《芽衣与爱莉希雅》。

我的信仰不是“更好的会在后面等着我们”，而是，“这是我一生的故事，我按照它，走完我的一生”。

现在真的得聊聊《你一生的故事》讲述了什么了。

“那是几年前的事，太空中飞来外星飞船，外星物体出现在草地上”。女主人公是一名语言学家，受军方邀请，参与与外星文明的交流。小说中叫这些外星生物：七肢桶。

可以理解，文明交流的第一步，是听懂对方的语言。语言分为两个部分：发音与文字。七肢桶是通过人类难以分辨的音频进行交流的，我们只能通过声谱仪记录下这些音频，这一过程尽管困难，但好在没什么难点。

困难的是文字——女主人公在与外星文明一段时间的交流后，意识到七肢桶的文字系统与发音系统，是两套完全不相关的系统。其文字系统，相当匪夷所思——他们的文字系统不注重字词顺序。

我把这最初一笔与完成后的句子互相比对。我认识到，这一笔参与了这个句子的好几个从句。开始时它是“氧”这个语标的一笔，明确有力，与其他笔画截然不同；接着它向下一滑，成为描述两颗卫星大小的比较词的一个组成要素；最后，这一笔向外一展，形成“海洋”这个语标拱起的脊梁。问题在于，这一笔是一道连续不间断的线条，而且是弗莱帕落笔的第一画。这意味着，早在写下第一笔之前，七肢桶便已经知道整个句子将如何布局。

这个句子的其他笔画同样贯穿了几个从句，笔笔勾连交织。抽掉任何一笔，整个句子的结构就将全然不同，只能重新组织。七肢桶并不是一次只写下一个语标，写完一个再写第二个。任何一道笔画都不只与一个语标关联，而是涉及好几个语标。字符与字符之间融合到这种程度，我以前只在书法作品中见过，尤其是以阿拉伯文字写就的书法作品。但那些作品是出自书法家手笔，事先经过精心安排。没有人能够边说边写，以这么快的速度完成如此复杂的作品。至少，人类做不到。

“这意味着，早在写下第一笔之前，七肢桶便已经知道整个句子将如何布局。”

盖雷头一次向我解释费尔马定律那天，他说过，几乎每一条物理定律都可以阐释为变分原理，但人类头脑在思考这些原理时往往将它们简化为表述因果关系的公式。这我能够理解：人类凭借直观手段发现的物理特性都是某一对象在某一给定时刻所表现出来的属性，诸如运动、速度等概念都是这样。按先后顺序、以因果关系阐述这些事件最方便：一个事件引发另一个事件，一个原因导致一个结果，由此引发连锁反应，
事物于是由过去的状态发展到未来的状态。

与人类相反，七肢桶凭直觉知道，物理属性本身是没有意义的，只有经过一段时间之后这些属性才有意义可言，比如“作用量”或其他我们人类需要用积分公式描述其定义的物性。这些属性用目的论加以解释最
便利：对事件作一段时间的观察，之后便会发现，这些事件本身具有某种要求，某种目的，比如最长时间或最短时间。对于一个事件来说，只有当它事先便了解自己的初始和终极阶段，才能达成它的目的。事先便知道“果”——先于“因”的启动便知道。

事实上，语言不仅是交流的工具，也是思考的工具。读者现在就可以尝试一下不借助语言的思考，你会发现这是不可能的。受物理发音的限制，音频必须是串行的，因此七肢桶的发音系统看起来并没有什么特别之处。可其文字系统却显出了一种浑然的特性，果先于因。文字系统可以反映出七肢桶的思想特性。

七肢桶，是预知未来的生物。不是像预言家那般能预知未来，而是本就知道未来，就好像因果定律于人类一般自然而然。

在七肢桶眼里，命运，是一份写好的剧本，摆在他们面前，他们所做的，就是扮演剧本中的自己，终其一生。

如果我试图对某个不曾预知这一切的人谈起这些事，他一定会问，要是七肢桶事先早已知道它们会说什么，会听到什么，为什么还要白费唇舌浪费语言？这是一个合乎情理的问题。但问题是，语言不仅仅是一
种交流工具，也是一种行动。按照语言—行为理论，诸如“你被逮捕了”“我将这艘船命名为……”“我保证”这些语词，其本身就是行为，仅当发出这些语词之后行为才算完成——话一出口，行为即成。对于这些行为而言，预先知道会说出什么话并没有什么关系。婚礼上人人都知道会有一句“我现在宣布你们结为夫妻”，这无关紧要。重要的是主婚人说出这一句话。没有这句话，单有其他仪式是不行的。对于述行语词而言，说话就是行动。对于七肢桶来说，所有说出口的话都是行为性的。它们所说的话不是用来交流思想，而是用来完成行为。无论什么对话，七肢桶全都事先知道双方会说些什么，这是事实。但为了让它们所知的对话变为真正的事实，对话仍然必须进行。

七肢桶无法用我们所理解的“自由”或“受约束”来描述。它们既不是怎么想就怎么做，也不是毫无能动性的机器人。七肢桶意识模式的独特之处不仅在于它们的行动与未来事件相合，而且在于它们的动机与未来事件的目的相统一。它们行动，使既定的未来成为现实，也使事件有了先后顺序。

自由并不是一种虚幻的假象，在先后顺序模式的意识中，它的的确确是真实的存在。在同步并举式的意识中，自由这种观念却没有多大意义，但同时也不存在“被迫”。两种意识不一样，仅此而已。这就好像哈哈镜前，看不见照镜子的人，只能看到镜中形象。镜中出现的也许是个绝代佳人，也许是个鼻子上长着大瘤子的小丑，下巴长到胸口。两种形象都是合理的阐释，没有对错可言。但是，镜子中一次只有一个形象，你无法同时看到两个。与此相类，预知未来又与自由意志产生了矛盾。正因为能够自由选择，所以我不可能预知未来。反过来说，如果我已经知道了未来，我便不可能反抗这个既定的命运，也不可能把我知道的未来告诉其他人——这也是一种形式的反抗。预知未来的人不会奢谈未来，读过岁月之书的人不会承认自己读过它。

人的剧本

（一段时间好忙就没写，回过头来看，感觉写的好羞耻啊。。。。。23333）

无论如何，即使是信奉宿命论的人，即使剧本真的存在，人是无法预知自己的剧本的。

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

去把这个不完美的故事，变成你所期望的样子。