forked from winxuan/winxuan.github.io
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
5d1b96e
commit 8b22f46
Showing
3 changed files
with
250 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5281,8 +5281,6 @@ public class HotelController { | |
|
||
``` | ||
|
||
|
||
|
||
#### 3.2.5.接收MQ消息 | ||
|
||
hotel-demo接收到MQ消息要做的事情包括: | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,203 @@ | ||
# linux复习 | ||
|
||
## 虚拟机 | ||
|
||
VMware为我们提供了三种设计模式: | ||
|
||
+ 桥接模式 | ||
|
||
 | ||
|
||
|
||
|
||
|
||
|
||
+ 主机模式 | ||
|
||
 | ||
|
||
+ NAT | ||
|
||
 | ||
|
||
## linux基础(我不熟练的基础) | ||
|
||
### 命令行快捷键 | ||
|
||
 | ||
|
||
### 用户组相关 | ||
|
||
|
||
|
||
cat /etc/passwd : 查看所有用户 | ||
|
||
last:查看用户最近登录记录 | ||
|
||
who:查看当前登录用户 | ||
|
||
id 【用户名】:查看用户的详细信息, | ||
|
||
useradd: | ||
|
||
passwd: | ||
|
||
usermod:修改用户的各种信息, | ||
|
||
|
||
|
||
我们来讲讲primary group与secondary groups的作用: | ||
|
||
+ primary group是用户创建时指定的群组,默认与用户名同名,作用是当用户创建文件、文件夹时会给创建的东西会被分配到主用户群组; | ||
+ 而secondary groups的作用就是给用户提供额外的权限,看名字就可以知道一个用户可以添加多个第二群组 | ||
+ 相关的操作有: | ||
+ 1、id:查看信息 | ||
+ 2、usermod -aG 群组名 用户名:添加到附加群组 | ||
+ 3、gpasswd -d 用户名 群族名:从附加群组中删除 | ||
+ 4、usermod -d 群组名 用户名:修改主群组 | ||
|
||
### 进程 | ||
|
||
ps aux(注意没有`-`):显示出所有的进程信息 | ||
|
||
pstree:更加直观的观察所有的进程 | ||
|
||
kill -9 PID:强制杀死进程 | ||
|
||
#### 进程与作业job的区别 | ||
|
||
**进程**是正在运行的程序的实例,它由操作系统调度和管理。每个进程有自己的地址空间、代码、数据以及程序计数器(PC),进程之间相互独立。 | ||
|
||
**作业**是用户在交互式 `shell(如 bash)中启动的`一个任务,通常由一个或多个进程组成。作业是操作系统中与用户交互时的概念,它的存在更多的是面向用户操作的。 | ||
|
||
 | ||
|
||
作业相关命令: | ||
|
||
jobs:显示当前会话中的所有作业及其状态。 | ||
|
||
fg %1 将后台作业恢复到前台运行。 | ||
|
||
ctrl + z: 将当前前台进程暂停并置于后台。 | ||
|
||
bg %1:将暂停的作业在后台继续执行。 | ||
|
||
kill %1:终止一个作业或进程。 | ||
|
||
### service | ||
|
||
服务的本质就是进程,通常会监听某一个端口,等待其他程序的请求:比如(mysqld , sshd、kafuka、nginx等),守护进程通常使用系统的进程管理工具来管理: | ||
|
||
```shell | ||
systemctl start nginx # 启动 nginx 服务 | ||
systemctl stop nginx # 停止 nginx 服务 | ||
systemctl restart nginx # 重启 nginx 服务 | ||
systemctl status nginx # 查看 nginx 服务状态 | ||
systemctl list-units --type=service | ||
systemctl enable/disable nginx | ||
|
||
``` | ||
|
||
有了命令,我们就知道怎么管理了,那么我们如何知道我们能管理什么服务呢?ubuntu中通常将能够直接使用systemctl管理的服务都存放在了`/usr/lib/systemd/system`目录下,这个目录下通常存放的时 `Unuit`文件,以 `.service`,一个典型的service文件内容可能如下: | ||
|
||
```service | ||
[Unit] | ||
Description=NGINX web server | ||
After=network.target | ||
[Service] | ||
ExecStart=/usr/sbin/nginx | ||
ExecReload=/usr/sbin/nginx -s reload | ||
ExecStop=/usr/sbin/nginx -s stop | ||
Restart=always | ||
User=nginx | ||
Group=nginx | ||
[Install] | ||
WantedBy=multi-user.target | ||
``` | ||
|
||
systemctl命令的本质其实是向 `systemd`发送管理命令,`systemd`是一个守护进程,它负责系统的初始化和管理,能够在系统启动时根据系统级别的需求自动启动相应的服务。当执行 `systemctl start nginx` 时,`systemd` 会根据 `/usr/lib/systemd/system/nginx.service` 文件来启动 `nginx` 服务。 | ||
|
||
### 网络状况 | ||
|
||
通常使用: | ||
|
||
`netstat -tuln`来查看当前计算机的网络使用情况, | ||
|
||
`iftop` 是一个实时显示网络流量的工具,可以显示哪些IP和端口正在传输数据。 | ||
|
||
### 目录结构 | ||
|
||
 | ||
|
||
 | ||
|
||
### 通配符 | ||
|
||
通配符 | ||
|
||
几乎所有`涉及文件名操作`的地方都要使用,通配符使得用户可以高效地操作和处理多个文件,避免了繁琐的单个文件名操作。尤其在文件管理、搜索、归档等操作中,通配符极大提升了工作效率。 | ||
|
||
 | ||
|
||
 | ||
|
||
### 上传下载 | ||
|
||
 | ||
|
||
|
||
|
||
 | ||
|
||
## linux高级 | ||
|
||
### 重定向: | ||
|
||
 | ||
|
||
 | ||
|
||
|
||
|
||
重定向输入stdin: | ||
|
||
 | ||
|
||
|
||
|
||
|
||
|
||
管道: | ||
|
||
 | ||
|
||
下面这张图解释了我对`tee`命令的一些疑惑,每次我是用tee命令写入文件时,终端也会有输出,原因就是这个是个`tee管道` | ||
|
||
|
||
|
||
 | ||
|
||
|
||
|
||
### 文件系统-磁盘 | ||
|
||
`分区`:分区是对磁盘的划分,相当于一个逻辑上的磁盘,每个分区可以被格式化成不同的`文件系统`;文件系统定义了如何将数据存储在磁盘上并且定义了读取、存储的方法; | ||
|
||
|
||
|
||
`lsblk` - 列出系统中所有的块设备,不仅仅是分区,还有整个磁盘信息:`sda` 通常是一个磁盘,而 `sda1`、`sda2` 等是磁盘的分区!!! | ||
|
||
`fdisk -l` 命令列出所有磁盘的分区信息,显示磁盘大小、分区的类型和文件系统等。 | ||
|
||
`df -h` 命令用于显示文件系统的磁盘空间占用情况。 | ||
|
||
du -sh /path/to/directory:查看目录或文件占用的磁盘空间 | ||
|
||
sudo mount /dev/sda1 /mnt: 用于将分区(如 `/dev/sda1`)挂载到指定的目录(如 `/mnt`)上。挂载后,你可以访问该分区的数据 | ||
|
||
|
||
|
||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,47 @@ | ||
# 操作系统 | ||
|
||
## 操作系统概述 | ||
|
||
操作系统定义: | ||
|
||
|
||
|
||
|
||
|
||
**every thing is state machine**:在计算机的世界里,任何东西都是状态机,对于CPU来说,其内部有寄存器,直接操作内存(有的甚至直接cpu内部集成内存),接收机器指令改变状态;对于汇编代码,我们可以使gdb对其实现清晰的观察,毫无疑问也是一个状态机;对于高级语言C来说,老师用了一个将汉诺塔非递归改写来举例说明其也是一个状态机; | ||
|
||
从软件的角度来看,我们来分析一下 `geditor`,这是一个简单的文本编辑器,类似于记事本,他的背后其实就是一个可执行文件,那么他是怎么做到当在键盘中敲下一个键盘,在屏幕上就能显示出这个字符呢?实际上在我们系统上有一个专门的进程用于屏幕显示,对于geditor来说,其只要告诉这个屏幕显示的进程我要在什么位置显示什么字符就行了,这个**告诉**就得依靠`系统调用`,另外没当我们按下一个键盘或者移动鼠标,操作系统通过设备驱动来感知到这些事件,之后会将这些事件传输给对应的应用程序(这个事件一般也是通过一个专门的进程管理的);我们可以看到,此时的操作系统就是在硬件设备的基础上进行了一层抽象,就是 `系统调用`,为操作系统上的应用提供系统调用; | ||
|
||
从硬件角度来说,操作系统的一切都是合理的,当我按下reset按键(或者开启)时,CPU都会按照规定将状态机的状态按照手册回归初始,PC指针会指向一个一个叫做firmware(以前叫作bios,后来为满足更加丰富的功能改为了uefi)的系统,起作用有很多,比如进行硬件的检查、硬件的各种配置,本质是此时是直接和硬件对接的,最终作用为加载操作系统;那么操作系统在哪呢?操作系统在一个称之为 esp(efi system partition)分区,这个分区并不大,存储者“xxx.efi”的**引导加载程序**,后续是由这个引导加载程序正式加载操作系统,我们在linux中可以看看目录结构: | ||
|
||
 | ||
|
||
我们可能会发现,为什么会有这么多的引导程序呢?实际上,`grubx64.efi`是一个非常好用的管理启动系统的一个引导程序,它可以帮助我们选择从哪个操作系统启动;这个程序需要在linux系统中安装; | ||
|
||
对于多核CPU来说,每一个核都有一个专门的`寄存器集合`,这个非常关键,这就能够保证了不同的状态机可以在不同的核心上同时执行,这是不违背everything is state Machine 这个理论的,而对于单核cpu来说,操作系统就是**状态机的集合**,每一时间操作系统选择一个状态机来执行,是一个状态机的管理者,但是站在整个系统的层面上,可以看作一个大的state machine; | ||
|
||
这门课上给我的第一个启发:当你觉得某件事麻烦的时候,那么必定有办法解决这种麻烦,如果没有办法解决,那么恭喜你,你如果能将其变得简便就或许会成为一个大牛(这种概率非常小非常小,百分之九十九点九别人都解决过);例如,当我们看见一个非常复杂的makefile,我们看着makefile的语法结构以及非常多的变量定义,我们第一反应:哇!这也太复杂了!!!,还是不看了,或者是直接复制非常不负责的复制扔给GPT(不是说这样依赖gpt不行,而是没有了自己的独立思考),此时我们不妨站在 everything is machine的角度,就是执行一条命令从一个状态到了另一个状态,当我们有了这种思维后,我们就绝对确定操作系统能够感知到状态如何变化,我们再一提问发现除了使用 `strace`命令查看系统调用外,还可以使用 `-nB`选项来查看make xxx 具体执行了什么指令,会一条一条罗列出来;这种思维我们需要熟练记忆!!!,其次,直接命令行的输出不好看,我们还可以使用 `| vim -`,并且将所有的 空格替换为 “ \n”这样会更加增加我们的阅读体验!!! | ||
|
||
|
||
|
||
|
||
|
||
> tips:在调试任何程序前都应该配置环境,例如我们在调试一个python程序前应该写一个 launch.json文件,以便对调试器进行更加细致的自定义,举个例子,如果你有一个需要特定环境变量或者不同工作目录的程序,`launch.json` 让你不必每次手动设置这些参数,而是将它们集中在一个文件中,便于复用和管理。 | ||
 | ||
|
||
随后老师放出了大招:使用`python`写了一个操作系统玩具,一共有三个系统调用,分别是read、write、spawn,然后里利用python提供的`yield`命令的特性,将系统调用修改成 `yield xxx`,这样当前执行的函数就会将执行权力交还给调用者,并且会保存当前状态机的状态,直到重新调用`send`函数才会继续执行; | ||
|
||
|
||
|
||
|
||
|
||
从数学角度来看,我们的程序就是一个确定性的数学模型,当我们的代码写好之后,他后面的状态也就确定了,这句话在并发编程前说都是对的,”“程序仅仅有两个不确定性”1:**处理器** 2、**外部输入**,初次之后的all都是确定性质的数学模型, | ||
|
||
## 多处理器 | ||
|
||
### 多处理器入门 | ||
|
||
我们的CPu通常会有多个核心,当我们有多个线程时并且这些线程不冲突,就可以放到每个核心上运行,这也就会使得在ubuntu系统上使用 top 看到的cpu使用率超过了100%; | ||
|
||
并且在我们能够创建线程之后,我们很容易去想这些线程是不是共享内存的呢?每个线程都独立拥有栈,那么这个栈的大小有没有限制呢?这就需要我们使用递归并创建局部变量消耗每个线程的局部空间,老师给了个例子,可以看看。 |