前言
从接触编程就开始使用 Git 进行代码管理，先是自己玩 Github，又在工作中使用 Gitlab，虽然使用时间挺长，可是也只进行一些常用操作，如推拉代码、提交、合并等，更复杂的操作没有使用过，看过的教程也逐渐淡忘了，有些对不起 Linus 大神。
出来混总是要还的，前些天就遇到了 Git 里一种十分糟心的场景，并为之前没有深入理解 Git 命令付出了一下午时间的代价。
先介绍一下这种场景，我们一个项目从 N 版本升到 A 版本时引入了另一项目的 jar 包，又陆续发布了 B、C 版本，但在 C 版本后忽然发现了 A 版本引入的 jar 包有极大的性能问题，B、C 版本都是基于 A 版本发布的，要修复 jar 包性能问题，等 jar 包再发版还得几天，可此时线上又有紧急的 Bug 要修，于是就陷入了进退两难的境地。
最后决定先将代码回退到 A 版本之前，再基于旧版本修复 Bug，也就开始了五个小时的受苦之路。
1、上下文切换
上下文定义
cpu发生进程或者线程切换时，所依赖的数据集合，比如一个函数有外部变量，函数运行时，必须获取外部变量，这些变量值的集合就是上下文。
引发问题
对于CPU密集型任务，多线程处理会发生上下文切换，会影响到执行速度，如果时IO密集型，多线程技术优点尽显。
如何减少上下文切换
- 无锁并发编程，锁的获取与释放会发生上下文切换，多线程时会影响效率。无锁并发编程就是将数据分块，每个线程处理各自模块。比如LongAdder中部分代码。
- CAS算法，并发编程时通过CAS算法更新数据，而不必加锁。如Java的atomic包下的工具类。
- 使用最少线程，减少不必要的线程创建，自定义线程池。
- 使用协程，在单线程中维护多任务调度，处理任务间切换，Golang对于协程的使用很强大。
2、死锁
死锁定义
死锁是进程死锁的简称，是由Dijkstra于1965年研究银行家算法时首先提出来的。
系统发生死锁现象不仅浪费大量的系统资源，甚至导致整个系统崩溃，带来灾难性后果。
产生死锁原因
- 系统资源不足
- 进程推进顺序不当
- 资源分配不合理
死锁产生的必要条件
- 互斥条件：一个资源只能被一个进程或者线程使用。
- 请求和保持条件：一个进程或者线程，请求资源的时候发生阻塞，对已经获取的资源保持不放。
- 不可剥夺条件：进程或者线程以获得的资源，在未使用完成时，不能强行剥夺。
- 循环等待条件：若干进程或者线程形成一种头尾相接的循环等待的资源关系。
这四分条件是死锁产生的必要条件，只要发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。
如何避免死锁
- 以确定的顺序获得锁
- 加锁时限
Lock接口提供了boolean tryLock(long time, TimeUnit unit) throws InterruptedException方法，该方法可以按照固定时长等待锁，因此线程可以在获取锁超时以后，主动释放之前已经获得的所有的锁。
《一线大厂Java面试真题解析+Java核心总结学习笔记+最新全套讲解视频+实战项目源码》开源
Java开发优秀开源项目：
-
ali1024.coding.net/public/P7/Java/git
- github.com/spring-projects
最后
由于篇幅原因，就不多做展示了
