大搜车一面总结

大搜车的面试体验还不错，毕竟没有迟到或者拖延时间，感觉面试的难度中等，而且能感觉出来公司是很注重技术的，一面顺利通过，二面要去杭州，我还要进行封闭开发，就给推了，而且听说“大扣车”的传闻，也不是很可惜吧，除了HR打电话的时候软绵绵的跟个还在上学的小女生似的，感觉缺乏职场素养，办事不够利落，其他的体验都还不错。大部分的问题都能答上来，挑几个值得记录的答案写一写。

1.锁的在jvm中的实现，内存模型，volatile的实现原理，volatile是否能保证i++操作的线程安全
2.concurrentHashMap的实现原理
3.HashMap初始化因子相关，初始化HashMap的时候指定长度可以提高效率，那么初始化长度有哪些依据，例如要存入12个k，v，初始化大小为多少
4.spring的ioc它的作用是什么，有什么优势
5.gc相关，如果频繁发生fullGC，可能原因有哪些，怎么排查
6.存在一个测试用例，包含1个主线程和10个子线程，主线程的执行需要10个子线程的结果，但是我不想让主线程等待10个线程结束才执行，怎么解决
7.redis和rabbitMQ
8.mysql大数据量的处理
9.你的优势是什么
10.你觉得你做过的东西牛逼的点在哪
11.rest接口相关，对幂等操作怎么理解
12.对加密算法有了解么，ISA相关

这里挑上面加粗的记录一下：

3.20201012更新：

今天翻看老博客，当时那个阶段看东西还是死记硬背，没有自己的思考，讲的也不严谨。其实源码里有写，在调用构造函数时，会调用tableSizeFor方法，取第一个不小于初始化长度的2的整数次幂作为HashMap长度。所以在实际业务中调用HashMap构造方法时，可以初始化为任何长度。但是从HashMap的内部源码实现上来说，HashMap的真实长度一定是2的整数次幂。原因就是下面以前写的内容。

3.初始化因子和初始化长度

默认的初始化因子为0.75，含义是如果HashMap的长度已经被占用了75%了，那么就需要进行扩容。这里面试官接着问，一般使用时会指定HashMap的长度，那么假如我想存入12条数据，我可以初始化长度为12么？答案是不可以 ，需要初始化为2的整数次幂，但是为什么我没答上，面试官说这个和初始化因子有关，因为初始化因子是3/4。这里我又查了下，发现主要原因是(table.length() - 1) & hash这个算法是根据key的哈希值来进行散列，只有在table.length()是2的整数次幂的时候才等于取模的操作，也就是只有2的整数次幂的时候才能够比较好的进行散列，不然的话有的table[]根本不会被散列到。

6.2019年5月21日更新：

今天没事来看下，发现6可能当时总结错了，其实面试官当时想问的是CountDownLatch等这种取代Object.wait()和Object.notify()方法的这种并发工具类吧。

6.将两个异步计算合并为一个——这两个异步计算之间相互独立，同时第二个又依赖于第一个的结果

是《Java8实战》中的内容，需要用CompletableFuture来实现。我这里说的是Future，但是Future存在以下缺陷：

• 将两个异步计算合并为一个——这两个异步计算之间相互独立，同时第二个又依赖于第一个的结果。
• 等待 Future 集合中的所有任务都完成
• 仅等待 Future集合中最快结束的任务完成（有可能因为它们试图通过不同的方式计算同一个值），并返回它的结果
• 通过编程方式完成一个Future任务的执行（即以手工设定异步操作结果的方式）
• 应对 Future 的完成事件（即当 Future 的完成事件发生时会收到通知，并能使用 Future 计算的结果进行下一步的操作，不只是简单地阻塞等待操作的结果）

Future以及相关使用方法提供了异步执行任务的能力，但对于结果的获取却是不方便，只能通过阻塞或轮询的方式得到任务结果。阻塞的方式与我们理解的异步编程其实是相违背的，而轮询又会耗无谓的CPU资源，而且还不能及时得到计算结果。

11.幂等操作：

**安全性：**无论请求多少次，都不会改变资源的状态。比如 GET 操作，无论执行多少遍，都不会改变资源的状态。所以对于 GET 类 API，在编写应用端代码时，切记要尽可能避免出现删除或者更新数据的逻辑。
**幂等性：**无论是执行一次，还是执行多次，效果是等价的，比如 DELETE，PUT 操作。以 DELETE 操作为例，删一次和删多次，效果都是该资源不存在了。

HTTP	安全	幂等
GET	是	是
POST	否	否
PUT	否	是
DELETE	否	是

HTTP GET方法用于获取资源，不应有副作用，所以是幂等的。比如：GET http://www.bank.com/account/123456，不会改变资源的状态，不论调用一次还是N次都没有副作用。请注意，这里强调的是一次和N次具有相同的副作用，而不是每次GET的结果相同。GET http://www.news.com/latest-news这个HTTP请求可能会每次得到不同的结果，但它本身并没有产生任何副作用，因而是满足幂等性的。

HTTP DELETE方法用于删除资源，有副作用，但它应该满足幂等性。比如：DELETE http://www.forum.com/article/4231，调用一次和N次对系统产生的副作用是相同的，即删掉id为4231的帖子；因此，调用者可以多次调用或刷新页面而不必担心引起错误。

HTTP POST方法用于创建资源，所对应的URI并非创建的资源本身，而是去执行创建动作的操作者，有副作用，不满足幂等性。比如：POST http://www.forum.com/articles的语义是在http://www.forum.com/articles下创建一篇帖子，HTTP响应中应包含帖子的创建状态以及帖子的URI。两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI；所以，POST方法不具备幂等性。

HTTP PUT方法用于创建或更新操作，所对应的URI是要创建或更新的资源本身，有副作用，它应该满足幂等性。比如：PUT http://www.forum/articles/4231的语义是创建或更新ID为4231的帖子。对同一URI进行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有幂等性。

如何防范 POST 重复提交
HTTP POST 操作既不是安全的，也不是幂等的（至少在HTTP规范里没有保证）。当我们因为反复刷新浏览器导致多次提交表单，多次发出同样的POST请求，导致远端服务器重复创建出了资源。

所以，对于电商应用来说，第一对应的后端 WebService 一定要做到幂等性，第二服务器端收到 POST 请求，在操作成功后必须302跳转到另外一个页面，这样即使用户刷新页面，也不会重复提交表单。

相关引用：

• 如何编写相对标准的后端项目（二）设计 Restful API
• java幂等性的控制(技术论坛上整理成文）
• 编程中的幂等性 —— HTTP幂等性
• Java里面CompletableFuture详解