为什么面试要问底层原理自我看法

       每次面试时别人都会问一些底层问题。但如果面试上后，去公司写的还是业务代码。为什么要这样呢，我面试过很多公司，但是很少有面试官知道为什么要去问底层。只是他们知道别人都在问，那我也要问，无论我要什么级别的人，我都要这样问这些问题，如果你不懂，面试就不通过，我不能拉低了我们公司的门槛。

       前一段时间在复习操作系统课程准备考试，然后在老师的一节课中，我突然悟到了这点。这节课讲的是死锁。

       在我对死锁一知半解的时候，只知道两个有两个方法，里面的逻辑是，第一个方法先执行A任务得到一个结果带入到B任务，第二个方法是先执行B任务得到一个结果带入到A任务。如果两个线程同时开始执行这两个方法，那么就会造成死锁。怎样解决这个问题呢。我当时回答是不要写类似上述方法就好了。

       后来学了死锁后，就能清楚的讲清楚里面的原理，首先还是基于上面的场景，怎样描述清楚呢。这就是产生死锁的四个必要条件：

 

首先操作系统定义了一个资源在同一时间内只能被一个线程使用。

1。互斥，第一个线程使用A接着要使用B，但是B被第二个线程占用着。造成互斥

2。不可抢占，接着上面，这时候第一个线程不能强行kill第二个线程。

3。请求保持，接着上面，第一个线程在没有使用B的时候，A就一直在使用着，不能被别的线程使用

4。循环等待，第一个线程占用着A，要使用B，在等待第二个线程释放B。但是第二个线程在使用B，要使用A，在等待第一个线程释放A。但是第一个线程占用着A，要使用B，在等待第二个线程释放B。但是第二个线程在使用B，要使用A，在等待第一个线程释放A。。。。。。。。。。

了解这些后，就来解决死锁的问题，破坏其中任意一个条件就能解开死锁。首先不可抢占和请求保持是计算机硬件，操作系统定义的。如果你想破坏这两个条件，那么你可以自己写一个新的操作系统出来。不过如果你破坏了这两个条件，还不知道会出现什么新的漏洞。

所以A使用B，B使用A这种行为是业务逻辑上的行为，我们可以针对这方面入手。破坏互斥，既然一个资源只能被一个进程使用。那么我在使用A之前，先拿到B的资源。都拿到了我才去执行这个线程的任务，否则我就释放A资源。这样就破坏了互斥。

然后破坏一下循环等待，既然在等待，那么我就设置让你超时自动释放，重新再来争夺资源，这样就破坏了循环等待。

 

所以说当我了解死锁原理和一知半解的时候就有很明显的两个不同之处。 第一讲解死锁清晰和不清晰，第二处理死锁正确方法和错误方法。程序的两个重点特性正确性和可用性。正确性就是代码的业务逻辑走的流程是否正确，这点基本上大多数程序员都能做到。可用性，程序成功运行的情况，如果程序奔溃了，不懂底层的人就没有分析bug原因的能力，可能处理的就特别慢。懂底层的人就会快速通过分析底层原理的方法推测bug在哪。

所以我认为之所以要去了解底层原理是因为。底层原理都是被设计出来的。只要是设计出来的，肯定会有漏洞。你只有了解了底层原理，才能写出一些避免这些漏洞的代码，也就是不会写出bug。 当你了解怎样避免漏洞时，你才能更快的从生产的bug中定位到问题所在。

比如说我现在对内存溢出这点了解的不是很多。如果我被问到，就会说程序所有资源占用的内存超过了虚拟机的最大内存，解决方案增加虚拟机的内存或者重启释放内存。如果懂内存写入和释放的算法原理，就会基于算法的优缺点去针对性的去调整，不仅能解决内存泄露这个问题，还能提高性能效率。