🪴 Obsidian Publish

@2 技术问题

19分钟阅读

技术

  • 比较常见的八股文可以看看  https://cyc2018.xyz/

  • 图解网络、操作系统、计算机组成  小林 coding

  • 八股文介绍时需要结合项目，比如 MQ 的可靠性和不可重复，正常情况消费一次，但是如果服务器重启或者接受服务重启，可能导致消息不可靠。最好本地搭建服务，模拟丢失情况并解决。把这个问题解决的思路和过程改成自己在工作中解决了这种问题，再加一点自己的思考，比纯背题好很多。

  • 工作 5-6 年，罗列熟练使用的技术，不合适。

  • 技能需要关联到相关的业务技能和沟通技能。

  • 修改后：

    • 七年 Java 后端开发经验，熟练使用 SpringCloud、SpringBoot、MyBatis 等主流框架。
    • 熟悉常见的数据结构、网络。主要涉及到电商、物联网等方面工作。独立推进项目开发
    • 对电商开发五年的开发经验，覆盖商品、订单、支付、财务等方面的开发。
    • 指导同事代码编写，并提供解决方案。定期向上级汇报项目的进度、遇到的问题和解决
    • 坚持写技术文章，访问量10万+,博客 : https://juejin.cn/user/3139860940197207

  • 看书的一点小建议 (opens new window)

    • CPU 飙升到 100% 如何处理

如何提高自己的工程能力

可以没事逛逛开源社区，了解下圈子里大家都在玩些什么，什么方案比较时髦，或者有什么需求还没有被解决。没想法可以从研读、魔改和仿制别人的项目入手。尝试动手搭一搭基础设施也是很好的。等到有想法了就自提背景和需求（挖坑），然后坚持到底把坑填好，填坑的过程就是对能力的锻炼。

可以看看《程序员的自我修养》

技术是为业务服务的，lz 可以想想目前负责参与的服务整个流程包括上下游是怎么串起来怎么 work 的，如果是你你会怎么设计，有实实在在的服务才不至于空洞

八股反驳总结

论点：

  1. 学 JVM 有用吗？有用，真有可能线上 OOM，通过动态数据定位到新生代和老年代比例问题。
  2. 简单介绍 CMS vs 三色标记出现的问题、CMS 短暂的 STW 问题引出的 G1、业务中用什么收集器、原因是什么
  3. 三次握手 vs 前两次握手不能带数据、怎么避免攻击、实际应用怎么做（相关过程分析、内核源码）
  4. volatile 关键字 vs 汇编文件的 lock 前缀，内存屏障，MESI 设计，MESI 与 volatile 的关系，MESI 优化队列，总线锁与缓存锁
  5. 使用了 mq，会注意看其他企业的相关实施方案、整理源码、进行压测

总结：

  1. 八股确实有用，可以当作拓宽自己知识面的工具，否则可能不会了解 JVM 内容，出现 OOM 也不知道正确的解决措施
  2. 在学习八股时，要记得深入了解，从语言的实现到操作系统的实现，查阅资料，阅读源码
  3. 面试时，不仅背知识，还要说出自己的理解、串联知识、结合业务场景、说出优化点和存在的问题。总之，体现自己思考的地方。
  4. 工作时，了解当前各个技术框架的使用原因，相似功能的为什么用这个框架而不用另一个框架；了解其他企业的实现方案，总结
  5. 万物离不开底层，吃透底层，再搞清楚业务，那么现在的很多中间件啊，分布式相关的知识啊，个人认为只是新瓶装旧酒
  6. 静下心来沉淀
  7. 《开发者内功修炼》、《代码整洁之道》、《程序员的基本素养》

八股反驳原文

首先得搞清楚八股是什么，一个知识点，你能把使用以及原理说出来，我称之为八股，但是你能把底层关联以及业务使用，优化历程也能搞清楚，我称之为能力。

固然，现在的 CS 基本已经形成了套路，一套一套的面试题，很多人无脑跟着背就行，甚至现在还有分公司，分部门，对应的面经和知识点都有人总结，可见八股影响之深。

但是退一步说，八股真的没用吗？八股不能体现你的能力吗？八股对于你的工作真的没有提升吗？

以我自己为例吧，这里不以偏概全哈，单纯就是分享一下自己的经历和看法。

例子一

刚刚上文学习路线有说到虚拟机的学习，很多人吐槽是不是这玩意没必要学？

但其实呢，我在实习的时候就遇到了自己的一个模块线上 oom 了，排查了很久通过动态数据定位到是新生代与老年代比例的一个问题。

当然了，对于很多大佬来说，这不算什么。但是对于我来说，假设我连这一块的基本知识都没掌握的话，我即便百度到了解决办法（例如无脑把比例调大，把内存调大），还是没法从根本上解决问题，所以我还是挺庆幸的，不然那天就背锅了…

例子二

再者说吧，还是八股的问题，面试的时候这可以作为你的一个优势，别人回答 CMS 就是简单的说下基本过程（我称之为八股），但是你回答可以把三色标记出现的问题以及 CMS 短暂的 STW 的问题引出 G1，并且还能举出例子，你在实习或者业务中使用的是什么收集器，为什么，怎么切换的（我称之为能力）。

例子三

再举个例子吧，一个很八股的问题，三次握手，老八股了。如果是简单的说出过程甚至需要说出中间的标志位，我都认为这是基础（八股），但是如果你能说出为什么前两次握手不能带数据，怎么避免攻击的，实际企业应用是怎么做的（开发者内功修炼里有相关文章），我称之为能力，我到现在还记得面试的时候把相关过程分析以及这一块内核的源码说出来的时候面试官惊讶的表情，这就不是八股了，这是你的优势。

同样的，工作中也是一样，我实习的部门是做底层开发的，网络嗅探，内核参数监控是常事，所以我会认为，作为一名程序员，不管说是不是真正用到了，但是实际上经常接触的东西，这些东西，还是值得多去了解的。

例如之前面经提到的 QUIC，实际上很多厂内部已经有类似协议开发的应用了，所以个人认为还算是一个很常见的东西。

例子四

多给一个例子吧，也是面试的小技巧，可以多说一点内容体现你的基本素养。

例如 Java 很熟悉的 volatile 关键字，假设说我是面试官，我的面试者只说到原子性有序性，JMM 内存模型这些，我会认为这是八股。

但是如果能说到汇编文件的 lock 前缀，内存屏障，MESI 设计，MESI 与 volatile 的关系，MESI 优化队列，总线锁与缓存锁，总线风暴，那么我认为这是能力。

至于这对工作有没有用，我个人认为，见仁见智吧（总线风暴就是一个点）。

例子四

上次面经文章分享的是我的实习项目，具体就不方便透露了，但是还是说一个点吧。

实习项目里使用了 mq，我在开发的时候会注意去看其他企业的相关实施方案，会去整理源码，然后开发过程中会进行压测，无意间我发现，我的 mq 使用的比隔壁一位高级开发还要溜，当然我就是随眼一瞟觉得他写的不怎么样。

那么我在面试的过程中，面试官同样的一个 mq 怎么保证消费可靠这种问题，我与别人回答的差距就出来了。

这里面我就不强调 os 和网络，数据库这些基础知识的重要性啦，我个人不是很建议出了什么新技术就莽着去学习，因为万物离不开底层，吃透底层，再搞清楚业务，那么现在的很多中间件啊，分布式相关的知识啊，个人认为只是新瓶装旧酒。

举上述例子我不是想秀自己的知识储备，这些在各位大佬面前真的是不值一提，羞愧万分，只是想通过个人在校招准备过程中说明一点。

就是八股 ≠ 无用，面试通过 ≠ 背八股。

很多时候你以为你问题都回答上来了，面试却挂了，面试官是在刷你 KPI（当然确实也有可能是）。

但是我更多的认为要多反思自己，是不是说到位了，是单纯的在背，还是说自己的理解，结合业务场景来说，并且说出优化的点，说出这种方法存在的问题，我个人觉得这是会让面试官眼前一亮的点。

同时，也是我在“八股”过程中的一点感悟吧，其实校招只是人生的一个阶段，欲速则不达，要珍惜现在能静下心来沉淀知识的时间。

程序员的内功修养与素养真的很重要，所以在“八股”之余会多去看看一些知识的源码以及企业里面的应用，会去看看《代码整洁之道》、《程序员的基本素养》等，总结成自己的笔记，未来希望能开源。

关于有人问到如何学的问题？

其实很简单，还是那句话，知识点都是那么多，深度和延伸得靠你自己了，一个大方向就是，从语言的实现到操作系统（网络）的实现，按照这个方向去搜集资料，去看源码，相信会很有收获的。

肯定有人提到，学这么多，进去还不是拧螺丝？

这个经典问题，只能说见仁见智了，我始终认为，有拧螺丝的时候，当然也有造航母的机会，这得看你的选择与把握机会的能力。

当然这里也要大厂小厂的争论，这里就不说了。不管在哪里，肯定会有拧螺丝的时候，但这不妨碍你有一颗自我学习，自己提升的心，与君共勉，这可能是我年轻气盛的想法。

grafana 是怎么设计的

原链接：被饿了么一面薄杀 - CC98 论坛

我面完脑子嗡嗡的，记得有一个是，因为楼主在阿里云实习，面试官举了一个阿里云的应用场景，比如阿里云横向团队开发了一个定制化的仪表盘的组件，提供给上百个不同的纵向的云产品团队使用，可以给用户呈现和监控用户所持有的不同的云产品的使用情况之类的一些参数，这些参数有些是所有云产品共有的，比如产品的使用次数之类的，有些是云产品特有的，你怎么开发。我说我把云产品共有的这些需要的参数写一个父类里，然后各个云产品的仪表盘去继承父类，定义自己特有的参数。面试官问，那上百个云产品，你就为了仪表盘这个组件，要定义上百个类？然后我想了一会儿想不出来直接摆烂了。。。

技术问题

一个技术领域，我们需要阐述哪些层面呢？我觉得可分两个维度，一个是技术的设计维度（从技术内部看），另一个是技术的应用维度（从技术外部看），如下图所示。

13 | 你真能讲明白技术吗? - 极客时间已完结课程限时免费阅读

如果面试官要你分析和解决一个问题，那就更复杂了：

  • 一个方案，不要只考虑成功的一面，还要考虑到失败后的应对方法。
  • 进而，选择和评判标准不要只按正反两种情况分析，而应该是灰度的。
  • 不要只按自己的视角去分析，应该考虑到影响的多方受众，换位思考。
  • 对于边界模糊的问题，是不是需要放到具体的情景中去讨论，才能有的放矢。相反的，对于回答问题的范围，如果加了不恰当的假设条件，把问题局限在某一个点上，是不是不能展示自我的全局视野。
  • 多个问题的回答中不要出现自相矛盾，观点前后要照应。

技术的细节问题。重要的不是知识，重要的是查找知识的能力。

  1. 与面试官沟通，完全理解题目意思（用自己的理解，复述一遍题目）。
  2. 然后看看能不能从面试官那边得到更多信息（就比如你先尝试说一个思路，如果不是面试官想听的，他会尝试去引导你）。
  3. 分析逻辑：对一个问题进行拆解，看看有那几个方面可以回答。
  4. 分点回答：构建出逻辑之后，分点把逻辑有条不紊的说出来（有逻辑的回答很重要）。
  5. 迂回战：对于一些很难回答的问题，需要转化，从另外一个角度进行解读；尽量避免直接的硬碰硬（也叫做和稀泥；比如别人问你哪样最不好，你可以诚实说一些无关紧要的最不好的品质，然后告诉别人你现在已经在努力改变了，而且有什么成效）。

你解决过最难的问题是什么？你是怎么设计这个系统的？你是怎么调试和测试你的程序的？你是怎么做性能调优的？什么样的代码是好的代码？等等。