fix: url

Author: wardseptember

docs/Java基础笔记.md

@@ -2298,7 +2298,7 @@ Java标准库自带的`java.util`包提供了集合类：`Collection`，它是
 - `Set`：一种保证没有重复元素的集合，例如，所有无重复名称的`Student`的`Set`；
 - `Map`：一种通过键值（key-value）查找的映射表集合，例如，根据`Student`的`name`查找对应`Student`的`Map`。
 
-<div align="center"> <img src="../imgs/FgPceiQ8m6EUWxVQtN6Riy5-FSYo" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/FgPceiQ8m6EUWxVQtN6Riy5-FSYo" width="600"/> </div><br>
 
 最后，Java访问集合总是通过统一的方式——迭代器（Iterator）来实现，它最明显的好处在于无需知道集合内部元素是按什么方式存储的。
 

docs/LeetCode终极版/Hot100分类.md

@@ -20,11 +20,4 @@
 
 # 未解决
 
-* [10. 正则表达式匹配](https://leetcode.cn/problems/regular-expression-matching/)
-
-```
-<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/myPictures/main/imgs/29011652795602_.pic.jpg" width="600"/> </div><br>
-
-```
-
-<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20210204225614.png" width="600"/> </div><br>
+* [10. 正则表达式匹配](https://leetcode.cn/problems/regular-expression-matching/)

docs/Nginx学习笔记.md

@@ -333,7 +333,7 @@ server {
 
 ## 配置高可用
 
-![](http://wardseptember.top/20200730211355.png)
+![](../imgs/20200730211355.png)
 
 当主服务器宕机，可以通过备份服务器提供服务。
 

docs/Redis原理笔记.md

@@ -219,7 +219,7 @@ redis4.0相对与3.X版本其中一个比较大的变化是4.0添加了新的混
 
 混合持久化同样也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据，如下图：
 
-<div align="center"> <img src="../imgs/20201030131617.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20201030131617.png" width="600"/> </div><br>
 
 ### 数据恢复
 

docs/git教程.md

@@ -106,7 +106,7 @@ git reflog
 
 Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支`master`，以及指向`master`的一个指针叫`HEAD`。
 
-![](http://wardseptember.top/20200812132553.png)
+![](../imgs/20200812132553.png)
 
 前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：
 
@@ -257,29 +257,29 @@ Git支持多种协议，包括`https`，但`ssh`协议速度最快。
 
 一开始的时候，`master`分支是一条线，Git用`master`指向最新的提交，再用`HEAD`指向`master`，就能确定当前分支，以及当前分支的提交点：
 
-![](http://wardseptember.top/20200812144337.png)
+![](../imgs/20200812144337.png)
 
 每次提交，`master`分支都会向前移动一步，这样，随着你不断提交，`master`分支的线也越来越长。
 
 当我们创建新的分支，例如`dev`时，Git新建了一个指针叫`dev`，指向`master`相同的提交，再把`HEAD`指向`dev`，就表示当前分支在`dev`上：
 
-![](http://wardseptember.top/20200812144407.png)
+![](../imgs/20200812144407.png)
 
 你看，Git创建一个分支很快，因为除了增加一个`dev`指针，改改`HEAD`的指向，工作区的文件都没有任何变化！
 
 不过，从现在开始，对工作区的修改和提交就是针对`dev`分支了，比如新提交一次后，`dev`指针往前移动一步，而`master`指针不变：
 
-![](http://wardseptember.top/20200812144429.png)
+![](../imgs/20200812144429.png)
 
 假如我们在`dev`上的工作完成了，就可以把`dev`合并到`master`上。Git怎么合并呢？最简单的方法，就是直接把`master`指向`dev`的当前提交，就完成了合并：
 
-![](http://wardseptember.top/20200812144456.png)
+![](/20200812144456.png)
 
 所以Git合并分支也很快！就改改指针，工作区内容也不变！
 
 合并完分支后，甚至可以删除`dev`分支。删除`dev`分支就是把`dev`指针给删掉，删掉后，我们就剩下了一条`master`分支：
 
-![](http://wardseptember.top/20200812144512.png)
+![](../imgs/20200812144512.png)
 
 首先，我们创建`dev`分支，然后切换到`dev`分支：
 
@@ -399,7 +399,7 @@ $ git commit -m "& simple"
 
 现在，`master`分支和`feature1`分支各自都分别有新的提交，变成了这样：
 
-![](http://wardseptember.top/20200812150713.png)
+![](../imgs/20200812150713.png)
 
 这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：
 
@@ -460,7 +460,7 @@ $ git commit -m "conflict fixed"
 
 现在，`master`分支和`feature1`分支变成了下图所示：
 
-![](http://wardseptember.top/20200812150741.png)
+![](../imgs/20200812150741.png)
 
 最后，删除`feature1`分支：
 
@@ -533,7 +533,7 @@ $ git log --graph --pretty=oneline --abbrev-commit
 
 可以看到，不使用`Fast forward`模式，merge后就像这样：
 
-![](http://wardseptember.top/20200812151242.png)
+![](../imgs/20200812151242.png)
 
 ## Bug分支
 

docs/多线程和高并发.md

@@ -338,7 +338,7 @@ synchronized是悲观锁，在操作同步资源之前需要给同步资源先
 
 #### Monitor
 
-<div align="center"> <img src="../imgs/20210320212838.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20210320212838.png" width="600"/> </div><br>
 
 Monitor可以理解为一个同步工具或一种同步机制，通常被描述为一个对象。每一个Java对象就有一把看不见的锁，称为内部锁或者Monitor锁。
 
@@ -370,7 +370,7 @@ public class SynchronizedDemo {
 
 上面代码反编译结果为：
 
-<div align="center"> <img src="../imgs/20201202150930.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20201202150930.png" width="600"/> </div><br>
 
 #### monitorenter
 
@@ -400,7 +400,7 @@ public class SynchronizedMethod {
 
 反编译结果：
 
-<div align="center"> <img src="../imgs/20201202151303.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20201202151303.png" width="600"/> </div><br>
 
 从反编译的结果来看，方法的同步并没有通过指令monitorenter和monitorexit来完成（理论上其实也可以通过这两条指令来实现），不过相对于普通方法，其常量池中多了ACC_SYNCHRONIZED标示符。JVM就是根据该标示符来实现方法的同步的：当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。 其实本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。
 
@@ -2175,7 +2175,7 @@ Reentrantlock用来实现分组唤醒需要唤醒的线程们，可以精确唤
 
 双向链表加一个volatile int state，链表的每一个节点是一个线程。
 
-<div align="center"> <img src="../imgs/20201208192923.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20201208192923.png" width="600"/> </div><br>
 
 #### VarHandle
 
@@ -3050,9 +3050,9 @@ public class ScheduledPoolDemo {
 
 * [源码解析](https://tech.meituan.com/2020/04/02/java-pooling-pratice-in-meituan.html)
 
-<div align="center"> <img src="../imgs/20210302105854.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20210302105854.png" width="600"/> </div><br>
 
-<div align="center"> <img src="../imgs/20210302105958.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20210302105958.png" width="600"/> </div><br>
 
 
 

docs/操作系统/常见锁.md

@@ -15,7 +15,7 @@
 
 **对于互斥锁加锁失败而阻塞的现象，是由操作系统内核实现的**。当加锁失败时，内核会将线程置为「睡眠」状态，等到锁被释放后，内核会在合适的时机唤醒线程，当这个线程成功获取到锁后，于是就可以继续执行。如下图：
 
-<div align="center"> <img src="../../imgs/20201019132107.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20201019132107.png" width="600"/> </div><br>
 
 所以，互斥锁加锁失败时，会从用户态陷入到内核态，让内核帮我们切换线程，虽然简化了使用锁的难度，但是存在一定的性能开销成本。
 
@@ -70,11 +70,11 @@ CAS 函数就把这两个步骤合并成一条硬件级指令，形成**原子
 
 读优先锁期望的是，读锁能被更多的线程持有，以便提高读线程的并发性，它的工作方式是：当读线程 A 先持有了读锁，写线程 B 在获取写锁的时候，会被阻塞，并且在阻塞过程中，后续来的读线程 C 仍然可以成功获取读锁，最后直到读线程 A 和 C 释放读锁后，写线程 B 才可以成功获取读锁。如下图：
 
-<div align="center"> <img src="../../imgs/20201019132141.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20201019132141.png" width="600"/> </div><br>
 
 而写优先锁是优先服务写线程，其工作方式是：当读线程 A 先持有了读锁，写线程 B 在获取写锁的时候，会被阻塞，并且在阻塞过程中，后续来的读线程 C 获取读锁时会失败，于是读线程 C 将被阻塞在获取读锁的操作，这样只要读线程 A 释放读锁后，写线程 B 就可以成功获取读锁。如下图：
 
-<div align="center"> <img src="../../imgs/20201019132203.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20201019132203.png" width="600"/> </div><br>
 
 读优先锁对于读线程并发性更好，但也不是没有问题。我们试想一下，如果一直有读线程获取读锁，那么写线程将永远获取不到写锁，这就造成了写线程「饥饿」的现象。
 
@@ -143,5 +143,5 @@ CAS 函数就把这两个步骤合并成一条硬件级指令，形成**原子
 
 关注我获得最新笔记、更多资源
 
-<div align="center"> <img src="../../imgs/20201013164148.png
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20201013164148.png
 " width="600"/> </div><br>

docs/操作系统/调度算法.md

@@ -183,7 +183,7 @@ FCFS 对长作业有利，适用于 CPU 繁忙型作业的系统，而不适用
 
 这里我整理了虚拟内存的管理整个流程，你可以从下面这张图看到：
 
-<div align="center"> <img src="../../imgs/20201018221116.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20201018221116.png" width="600"/> </div><br>
 
 所以，页面置换算法的功能是，**当出现缺页异常，需调入新页面而内存已满时，选择被置换的物理页面**，也就是说选择一个物理页面换出到磁盘，然后把需要访问的页面换入到物理页。
 
@@ -254,7 +254,7 @@ FCFS 对长作业有利，适用于 CPU 繁忙型作业的系统，而不适用
 
 我画了一副时钟页面置换算法的工作流程图，你可以在下方看到：
 
-<div align="center"> <img src="../../imgs/20201018221317.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20201018221317.png" width="600"/> </div><br>
 
 了解了这个算法的工作方式，就明白为什么它被称为时钟（*Clock*）算法了。
 
@@ -276,7 +276,7 @@ FCFS 对长作业有利，适用于 CPU 繁忙型作业的系统，而不适用
 
 我们来看看磁盘的结构，如下图：
 
-<div align="center"> <img src="../../imgs/20201018222940.png" width="600"/> </div><br>
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20201018222940.png" width="600"/> </div><br>
 
 常见的机械磁盘是上图左边的样子，中间圆的部分是磁盘的盘片，一般会有多个盘片，每个盘面都有自己的磁头。右边的图就是一个盘片的结构，盘片中的每一层分为多个磁道，每个磁道分多个扇区，每个扇区是 `512` 字节。那么，多个具有相同编号的磁道形成一个圆柱，称之为磁盘的柱面，如上图里中间的样子。
 
@@ -394,5 +394,5 @@ FCFS 对长作业有利，适用于 CPU 繁忙型作业的系统，而不适用
 
 关注我获得最新笔记、更多资源
 
-<div align="center"> <img src="../../imgs/20201013164148.png
+<div align="center"> <img src="https://raw.githubusercontent.com/wardseptember/notes/master/imgs/20201013164148.png
 " width="600"/> </div><br>