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