面试成长总结帖
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了面试成长总结帖，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含12250字，纯文字阅读大概需要18分钟。
内容图文
面试成长总结
答题技巧总结：
1.简历：
- 1.简历相当于给面试官的一个大纲，想好自己想让面试官问什么，就突出什么，不重要的忽略掉；
- 2.确定好大纲后，还要写的有条理，就跟写代码一样，结构要清晰，重点要明朗（这个我做的不好，嗨）；
- 3.如果可以的话，可以根据心仪岗位修改简历，尽量靠拢（我就不行，因为懂的太少了，嗨）；
2.面试前准备：
- 1.看面经，找面试热点问题，面试喜欢问哪些方面的知识点，然后私下系统的学一下，不用很精通，只要让知识成体系就好，因为碎片知识是最容易忘掉的；
- 2.弄清自己的项目，项目背景，项目架构，自己做的这个模块在项目里起什么作用，遇到了什么问题，有几种方案解决，方案优劣点，市面上怎么解决，我们选了什么方案，为什么选这个方案；
- 3.项目弄清后，一要锻炼表达能力，使用结构化思维总分总的讲，争取自己讲完能给对方传递一个脑图，要做到有效沟通；二要想想这段表达里有没有突出你的特点：比如对知识点掌握的熟悉程度，良好的执行能力，工作学习自主性强不强等等，要传递积极能量，成长讯息；
- 4.投简历不要选太烂的公司，差的面试官不会给人任何成长，只会浪费时间；
3.面试技巧：
- 1.自我介绍：一二分钟，有条理，名字，在职情况，过往经历，做了什么，介绍项目，第一个项目，项目背景，产出，做了什么努力，获得了什么成长。就是一个原则：要有逻辑，要言简意赅，要传递一个脑图信息，能把话说清楚，对方能脑补出你的经历；
- 2.讲项目：
- 1.项目的整体背景，解决什么问题，自己做了啥，做的东西在项目中的定位，项目的亮点，价值点；
- 2.在项目里收获了什么：技术和职业素养都可以说，技术上比如解决了什么问题（体现私下学习，主动学习，分析解决问题的能力），职业素养上比如，沟通，表达，协调，推进，目标感等等；就是一个原则：讲清楚自己的东西，并突出重点，同时传递自己的成长信息；
- 3.问基础：经验不论深浅都要成体系，最好在私下学习的时候就给自己画脑图；
- 4.问技术：
- 1.从应用场景，技术特点讲；
- 2.要有非常擅长的技术，能说出1，2，3的那种；
- 3.技术横向比较，不熟的了解下，只要不太离谱，平时要注意拓展知识面的广度，面试要表达一点学习能力和学习欲望；
- 5.总结：
- 1.结构化思维很重要，首先要着眼于大框架，再精于细节，先要大而全，再要小而美；
- 2.表达很重要；一定要一条一条的表达，尽量不要边想边说，就是想着给别人传递一个脑图过去；
- 3.硬实力不够，软实力凑，多表现自己的学习能力，潜力，自主能动性之类的，做充足的准备；
- 4.面试心态要自信点：就当是去跟厉害的人学点东西了，比如当面试官问我，HashMap为什么链表长度到8的时候才转为红黑树，不是4，不是5，如果我联想到时间复杂度，我就能说，长度在4以内链表和红黑树平均耗时是一样的，这说明我学习主动性不够，没把知识点串起来，应该是要在平时好好积累的；
常考面试题：
Java基础常考题：
- 1.基础过点推荐：
1.1.https://snailclimb.gitee.io/javaguide-interview；
1.2.https://www.cnblogs.com/xrq730/ - 2.HashMap：
- 1.结构：jdk1.7是数组+链表，jdk1.8数组长度超过64，链表长度超过8，就把链表转化为红黑树；
- 2.rehash：1.负载因子，扩容倍数等；2.扩容过程：1.7的多线程环境会造成死锁，1.8不会，因为它找到了1.7中rehash的规律，这个改天重开一个帖子(为什么是8才转化为红黑树呢？因为为4的时候，访问红黑树的复杂度和链表是一样的，为5，6，7时，可以转，但是TreeNodes占用空间是普通Nodes的两倍，根据泊松分布，为5，6，7的概率还蛮大，会耗费大量存储资源，但是查询性能收益不大)；
- 3.红黑树和二叉平衡树的区别：红黑树适合树结构频繁变动的场景，二叉平衡树适合相对静态的场景，但是从理论上说查询效率要比红黑树高一点；
- 4.CurrentHashMap：线程安全的HashMap，dk1.7是分段加锁，jdk1.8：给数组的每一个node以及链表的next指针加锁 + CAS，提高并发度；
- 3.线程池：解决什么问题，用过没，怎么用，都有哪些参数，参数的意义；
- 4.JVM:
- 推荐书籍：深入理解Java虚拟机
- JVM组成，对象怎么创建的，创建的对象放在哪，对象什么时候回收，回收算法有哪些，垃圾处理器有哪些，类什么时候回收，常量什么时候回收；
- 类加载：类的加载过程，双亲委派模型；
- 多线程：synchronized关键字（对象锁，类锁），Reentrantlock和synchronized的区别，Volatile关键字，ThreadLocal，轻量级锁，自旋锁，偏向锁，JMM内存模型等等，场景题：主线程等待子线程完后才能继续运行要怎么做，生产者消费者模型等；
- 我记忆深刻的一个问题：多态是如何实现的，当时没回答上来，这里记录一下：方法调用这里分为三种：1.方法为静态的或私有或final修饰，他们不会有其他版本，故可以在编译期间就将符号引用解析为直接引用；2.静态分派：最典型的案例是重载，它依赖于对象的静态类型来定位方法执行版本，发生在编译阶段，属于多分派；3.多态：3.1.找到操作数栈顶的变量的实际类型，记为C；3.2.如果C中有相应的方法，则直接调用；3.3.如果没有，则按照继承关系从下往上搜索，重复3.2的判断；3.4.若最终都没找到，责任抛出异常；这个过程是在运行时完成的（理论参考：深入理解Java虚拟机 8.4节，方法调用）
- 5.Mysql:
- 1.索引：为啥用索引，索引的结构，为啥是B+树，什么情况适合建立索引，索引覆盖，索引下推，回表，最左前缀，数据库死锁怎么处理，删除大量数据时要怎么处理索引等等
- 2.隔离级别：隔离级别有哪些，各个隔离级别不能避免什么问题；
- 3.事务：事务的四大特性，事务要怎么实现，悲观锁，乐观锁，意向锁，间隙锁，MVCC；
- 4.推荐帖：https://github.com/whx123/JavaHome/tree/master/Java%E9%9D%A2%E8%AF%95%E9%A2%98%E9%9B%86%E7%BB%93%E5%8F%B7
- 6.操作系统:知识点看看基础过点推荐的那个博客就行，可以配合着这个帖子理解：https://mp.weixin.qq.com/s/rlUuO-WQE6vOL3wWtzzK2Q
- 6.设计模式:最好在自己的项目里找一找哪里用到过，至少单例肯定用过的，单例要闭着眼睛都会写，会几个常用的就行；
Kafka常考点：
- 1.kafka概述：
- kafka推荐书籍：Apache kafka实战
- 背景：做流量削峰，应用解耦用的，可以讲一下它在组织架构中的作用；
- 特点：吞吐量很高：页缓存，零拷贝，partition，批量写等等；
- 和其他消息中间件的对比；
- kafka版本变迁，了解就好；
- 2.消息不丢失：
- 生产者：1.ack = -1/all；2.采用异步+回调或同步的方式发送消息；3.缓冲池满了抛异常，而不是直接丢弃数据；4.sender线程一条一条的发送数据，避免因为重试造成消息乱序；5.重试次数设置为无限（只要回答出前两个就行）；
- Broker端：1.每份数据保留多个副本；2.禁止不洁的leader选举；
- 消费者:1.提交消息使用手动提交（其实不论是自动提交还是手动提交，对于kafka而言，消费者端是不会丢数据的，但是从消费者的角度看来，这条消息我没用到业务里，就相当于数据丢失了）；
- 3.精确一次消费：
- 1.设置手动提交消息位移；
- 2.为每条消息都加上PID，应用拉取到数据后，先判断PID是否已经被使用，注意标记PID为已使用的代码，要和业务代码写到一个事务里，业务修改了PID的状态后又崩溃时，要回滚PID的状态；
- 3.注意事务里只能写必要的业务代码，否则若业务执行长时间不提交offset，Kafka会认为该consumer离组，进而进行consumer重平衡，影响业务吞吐量和架构稳定性；
- 4.消费者组知识点：
- 1.partition和消费者组中消费者的对应关系（消费者组C消费Topic中的数据时，C中含有的消费者不应该超过Topic中Partition的数量，否则会造成消费者资源限制）；
- 2.给消费者分配partition的负载均衡算法；
- 3.消费者重平衡的触发场景 + 重平衡过程；
- 5.kafla有趣的一些实践：
- 1.丢数据案例1：生产者端忘记使用flush方法：生产者是将数据发送到缓冲池中，当缓冲池大小超过阈值，或者时间超过阈值才会将缓冲池里的数据发送到broker中，所以在关闭kafka的生产者进程时，记得使用flush方法将最后一批数据发到broker里，否则会丢失缓冲池的数据；
- 2.丢数据案例2：优先副本均衡为ture+auto.offset.reset = largest+Kafka集群环境重建：1.环境参数设置：优先副本均衡为ture+auto.offset.reset = largest；2.扩容策略：在做kafka集群扩容时，因为数据量小，放弃了平滑扩容，选择等数据全部消费完，根据现有集群规模重建一套集群；3.问题发生步骤：集群新建完成后，假设此时集群有A，B，C三个节点，A节点先启动，所有partition的leader都在A节点上，消费者组消费时得到的leader为A，接着B和C相继启动，由于优先副本均衡为ture，所以部分leader被均衡到B和C上面，导致消费者组拿到的部分leader是错的进而不能进行消息消费，等5分钟后消费者组重置了元数据得到正确leader后就可以正常消费了，但是由于这个集群是新搭的，消费者组里面没有位移，auto.offset.reset = largest参数生效，消费者组只能从最新位移处开始消费，因此丢失了前5分钟的数据；4.解决方案：1.使用kafka平滑升级；2.将优先副本均衡机制关掉；
- 3.异常断电导致Broke无法启动：官方issue:https://issues.apache.org/jira/browse/KAFKA-3919;相关分析帖：https://cloud.tencent.com/developer/article/1694186（这个帖子的优化方案很有用）。我自己读官方issue得出的这个问题发生的原因（不一定对）：前提条件：1.禁止不洁的leader选举；2.kafka消息采用压缩；场景：假设现在集群有3个节点，A,B,C;A为leader；问题发生步骤：1.数据写入是先写到leader里的，假设A中有2000条数据；2.follower同步leader中的数据，假设B中有数据1950条，C中有数据1900条，且B和C都在ISR内；3.假设此时A,B都挂掉，此时C成为leader，C中有数据1900条；4.启动A,B，A,B会根据C中的offset做日志截断，理论上来说，A和B都应该截断到1900；但是因为我们kafka消息采用了压缩，这个1900刚好在压缩日志的中间，而A,B会根据压缩日志最尾端开始截断，假设最尾端为1910；故A,B此时的最尾端的offset为1910；5.此时C为leader，offset为1900，开始从1901开始接数据，A，B从C中同步数据；6.通过以上步骤，B，C的offset为1900,1901,1902,1903,1904,1905,1906,1907,1908,1909,1910,1901……,这样kafka中的offset就变成了非单调递增；7.B，C中的索引日志段构建时，要依赖完全单调递增的offset，否则就会删了，重新构建，由于我们的offset日志有问题，故索引段的构建会不停重复这个步骤，导致kafka服务器崩溃。
hbase常考点：
- 1.hbase概述：
- 推荐书籍：Hbase原理与实践；
- 背景：解决海量数据的写入与读取；
- 解决方案：LSM树，将一次磁盘随机写转换为一次内存随机写 + 磁盘顺序写；
- 存储：物理视图是KV键值对存储，逻辑视图是表结构形式，有列簇概念，Key 是rowkey + timestamp + type + column family + column符合结构，存储的数据是多版本，多维，稀疏的；
- 特点：写入的是一条条记录，而不是数据，需要compaction操作减少读延迟；
- 缺点：对二级索引不够友好，我们项目里用了es来解决这个问题；
- 2.hbase读流程：
- 1.概述一下读：例如hbase存储的是操作记录，需要把这条数据的所有数据读出来，过滤得到结果返回；
- 2.获得rowkey对应的RegionServer（客户端缓存了mate表，以及mate表失效怎么处理，zookeeper在这里是什么作用）；
- 3.Scanner体系（结构，作用）；
- 4.使用归并算法读出Scanner体系过滤出来的HFile以及Memstore,再根据查询条件做进一步过滤；
- 5.blockcache在这里的作用，怎么往blockcache里写，怎么从blockcache读；
- 6.读出来的结果是使用next一批一批的给客户端的，这里客户端还有几个参数可以看下；
- 2.hbase写流程：
- 1.概述一下写：例如hbase是将随机磁盘写转换为内存随机写+磁盘顺序写，所以用到了HLog和Memstore，内存超过阈值后要落盘，所以有flush操作形成HFile；
- 2.获得rowkey对应的RegionServer，类似读流程；
- 3.写的顺序：HLog -> MemStore -> flush形成HFile,要了解一下细节，面试有可能会要求细说，以及HLog，MemStore的作用是什么；
- 4.形成HFile的步骤，HFile有哪些Block，每个Bolck是干什么的；
- 5.布隆过滤器弄清楚；
- 3.compaction：
- 1.compaction为了解决什么问题，大致原理（把小文件读出来使用归并算法合并）；
- 2.compaction的副作用；
- 3.compaction分类，为什么要这么分类；
- 4.compaction何时触发，流程；
- 5.compaction会不会造成数据丢失，会不会造成数据不一致；
- 4.region分裂：
- 1.region分裂的本质是解决什么问题（分布式系统数据均衡的问题）；
- 2.region分裂的特点（全程都是事务操作，开始子region并没有真的分出来，而是在父Region上建立一个Reference文件，查询查的还是父Region）
- 3.什么时候真正进行分裂，并删掉Reference文件：Major ComPaction中；
- 5.Rowkey设计：
- 1.唯一性，散列性，长度不要太长；
- 2.实践中，我们用了加盐 + rowkey反转两种设计；
- 6.Hbase场景题：
- 1.使用Hbase实现事务：我回答用zookeeper + 2PC提交，应该答得不太好；
- 2.Hbase只读最新的数据，可以只读Memstore吗：不可以，假如一个业务使用时间戳做版本号，然后在写入数据的时候，设置了旧的时间戳，那么只读memstore就会读到旧数据。
其他大数据问题：
- 1.spark core：
- 1.考原理（内存计算+迭代式计算+计算依赖于数据+宽窄依赖的定义与划分）；
- 2.spark任务提交：Action算子 -> DAGSchedule ->TaskScheduler -> ExecutorBackEnd -> Executor这个流程重的大致过程）；
- 3.考简单的spark程序，例如wordcount；这一块主要是我实践不多，能考的肯定不止这一点；
- 2.Redis：
- 1.基本数据类型，AOF，RDB，缓存击穿，缓存雪崩，zset底层实现（跳跃表，hbase里也有用）；
- 2.分布式事务（setnx实现：若setnx成功，表示加锁成功，使用完成后将set的key删掉即可解锁，为了避免客户端崩溃导致无法解锁，setnx添加的key都会设置ttl，为了处理不同事务耗时长短不同的问题，ttl时长可以追加）zookeeper中用的时临时节点+watcher机制实现；
- 3.zookeeper：1.临时节点，watcher机制，怎么用它实现master高可用，分布式锁；2.考2pc提交；
- 4.其他：MapReduce过程，hive常用的sql（我不会，嗨)；
大数据场景题：
- 场景：总是处理海量数据，找出最大的前K个啦，排序啦之类的；
- 解决方案：1.分而治之/hash映射 + hash统计 + 堆/快速/归并排序；2.双层桶划分；3.位图/布隆过滤器；4.外排序；
- 案例：参考帖子：https://blog.csdn.net/qq_38835878/article/details/98318716
常考算法：
- 1.排序算法（重要）：冒泡，选择，插入，快排，堆排，归并，闭着眼睛都要会写的那种；
- 2.树的基本操作（重要）：前序遍历，中序遍历，后续遍历的递归和非递归版本，层序遍历，之字型层序遍历，二叉树高度之类；
- 3.链表：链表反转，判断链表有环，链表环的起始位置，头插法，尾插法；
- 4.栈：使用栈实现队列，使用栈进行四则运算等等；
- 5.队列：约瑟夫环，使用队列实现栈等等；
- 6.动态规划：基本的动态规划问题，例如字符最长子序列等，进阶的话，可以学背包问题；
- 7.字符串（重要）：经典算法，例如最长回文子串等
- 8.推荐书籍：数据结构与算法 经典问题解析（Java版）；
- 9.习惯养成：坚持刷leetcode的每日一题，培养逻辑思维；
- 10.推荐题集：牛客网——研发最爱考，150道题刷一刷。
内容总结
以上是互联网集市为您收集整理的面试成长总结帖全部内容，希望文章能够帮你解决面试成长总结帖所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。
来源：【匿名】