绝对
. 绝对并发的含义
- “绝对的并发”通常是指多个任务在同一时刻真正同时执行。在单处理器（单核CPU）系统中，由于CPU在某一时刻只能处理一个任务，所以实际上是通过时间片轮转等调度方式，让任务看起来是同时执行，这不是绝对的并发。而在多处理器（多核CPU）系统中，多个任务可以在不同的核心上真正同时运行，更接近绝对并发的概念。
2. Goroutine与并发
- Goroutine不能实现绝对的并发。Goroutine是Go语言中的轻量级线程，由Go运行时（runtime）调度。Go语言通过Go运行时的调度器来决定何时运行哪个Goroutine。
- 在单核CPU上，Go运行时的调度器会在不同的Goroutine之间快速切换，给人一种并发执行的感觉，但实际上同一时刻只有一个Goroutine在执行。在多核CPU上，Go运行时可以将多个Goroutine分配到不同的核心上同时执行，但这仍然受到CPU核心数量、系统负载等因素的限制，也不是绝对
. 正常 rebase 无丢失情况
- 假设你有一个 master 分支，初始提交为 commit1 ，内容是一个简单的Python文件 app.py ，里面只有一行代码 print("Hello") 。
- 你从 master 分支创建一个 feature 分支。在 feature 分支上，你进行了两次提交。 commit2 添加了一行新代码 x = 5 ， commit3 又添加了一行 print(x) 。此时 feature 分支的代码文件 app.py 中有三行代码：
- print("Hello")
- x = 5
- print(x)
- 当你在 feature 分支上执行 git rebase master 时，Git会将 commit2 和 commit3 重新应用到 master 分支最新提交（这里就是 commit1 ）之后。操作完成后， feature 分支的提交历史看起来像是这些提交是在 master 分支的 commit1 之后连续完成的，没有丢失任何提交，通过 git log 依然可以看到 commit2 和 commit3 。
2. 冲突处理不当导致丢失情况
- 假设 master 分支的 app.py 文件在你开发 feature 分支后又有了新的提交 commit4 ，它修改了第一行代码为 print("Hi") 。
- 当你在 feature 分支上执行 git rebase master 时，在重新应用 commit2 （添加 x = 5 ）时可能会出现冲突，因为第一行代码在 master 分支已经改变了。
- 如果你错误地解决冲突，比如直接删除了 commit2 和 commit3 相关的代码修改，并且没有通过正确的 rebase 流程（如没有使用 git rebase --continue ），而是强制进行了其他操作，如 git reset --hard 到某个旧的状态，那么 commit2 和 commit3 的提交记录就会丢失。之后你通过 git log 查看 feature 分支时，就找不到 commit2 和 commit3 相关的记录了。
提示
