有程序员会吐槽说他去面试的时候对方的公司从业务上看没啥高并发的为啥一来就是老问高并发的呢?这跟他们公司有无并发场景有啥关系呢? 一个是跟面试官自己的知识储备有关再者你就算公司的业务场景再简单也存在并发的场景的。就是说并发的场景可能存在你就得考虑不然会出故障。且并发的事情理解起来本身也不太容易作为重要的考核点是非常正常的。我先举一个流量很低但是又不得不考虑并发的场景就拿我们这边的门店收货来说目前门店不多但是供应商送货到门店后门店的店员收货时不只是店长可以收货其他店员也是可以的。那问题来了两个店员可能存在同时收货的场景那你是不是得考虑了?是用锁还是使用有唯一索引的流水表且前端用户体验你是不是也得一并考虑?这些产品经理会告诉你吗? 不会他只是考虑功能而已。你作为程序员不去想这个事情吗?记住由于业务性质流量很低的也是存在并发场景的。因此要考察。另外正如我上面提到的并发这个知识点本身不容易理解因此他也是会成为一个必考的知识点你能理解并发相关的知识吗?如果你本身以前的公司参与的项目都是高并发的项目反而面试官会问你在实际工作中是如何处理并发的未必会深入问你知识点。如果你以前参与的项目流量很低反而是要深入的问并发知识点这是事实。这是一个区分度的问题候选人那么多并发知识的能否理解的很好就是一个重要的区分度指标。我去哪家公司带团队面试候选人的时候并发知识点我是必问的。常年如此。我就拿一个最简单的线程安全相关里其中的一个知识点锁我多个线程进入synchronized代码块时会被怎么处理?候选人拿到锁的线程可以进入我那拿不到锁的线程呢?候选人被挂起。我有没有办法不被挂起?候选人可以自旋?我一直自旋?候选人有超时的过了后才被挂起?我。。。一直问下去。候选人一直到回答不出来为止。要是都能回答出来呢那挺好的加分。还有像什么读写锁这种不太好理解的我也是经常问的。这些并发知识你日常没去研究一下怎么可能理解到位呢?因此这里就隐含了一个重要的点你平常有去研究技术。这个超级关键的而不是随意的完成日常需求交付就完事了。你有无兴趣去一探究竟。请注意兴趣有无去折腾过一下。我接触过的高手都是很爱折腾和研究的。请记住这句话。最后像我这种知识储备还行的假设就算公司的业务里永远没有并发的场景。那不好意思我也问的。除了刚才上面提到的并发作为一个考核项必问外也跟面试官自己风格性格有关的。小结你就作为一个面试专项好好准备就可以了一个月的准备时间不够就三个月再不够就半年。肯定可以慢慢理解对的。