HashMap内存溢出

bootsrc · bootsrc · commit 101de7ea83f6 · 2019-04-30T17:17:29.000+08:00
diff --git a/README.md b/README.md
@@ -138,14 +138,19 @@ Senior Java engineer interview exams in 2019
 
 * 自己查漏补缺
 
-    * sql遗漏知识点
+  * [微服务调用超时的处理方案](readme/call-timeout-process.md)
+
+  * sql遗漏知识点
+
+  答案: exists与in的区别和各自的应用场景是什么？    having的作用是什么？
+  truncate与delete的区别.
+  Oracle的over(), partition by的使用。partition by与group by的区别。
+
+  * valotile关键字有什么作用
+
+  * duboo或者spring cloud微服务调用超时应该怎么处理
     
-    答案: exists与in的区别和各自的应用场景是什么？    having的作用是什么？
-    truncate与delete的区别.
-    Oracle的over(), partition by的使用。partition by与group by的区别。
     
-    * valotile关键字有什么作用
-
 <hr/>
 
 * 京东金融
@@ -256,10 +261,10 @@ String s = " z111,c888,n222,,,g000, t333,a999,c888 ,p000 ,z111 ";
 
   *1.[Spring bean依赖注入的时候怎么解决bean之间的循环引用问题](https://www.cnblogs.com/bhlsheji/p/5208076.html)
 
-  *2.如何自己去实现一个WEB框架，怎么实现类似于SpringMVC里的@RequestMapping
+  *2.如何自己去实现一个WEB框架，怎么实现类似于SpringMVC里的@RequestMapping,用什么匹配算法速度最快
   
 * 拍拍贷
-  * [使用HashMap的时候如何避免内存泄漏](readme/)
+  * [使用HashMap的时候如何避免内存泄漏](readme/hashmap-memory-leak.md)
 
 ## 更多Java面试题
 
diff --git a/readme/call-timeout-process.md b/readme/call-timeout-process.md
@@ -0,0 +1,51 @@
+# 微服务调用超时处理
+
+* 服务之间调用的交互模式
+  * 同步
+  * 异步
+  * 消息队列
+
+* 最简单的处理策略
+
+  微服务调用，一般是使用同步调用。通常的做法是超时几次后采用熔断策略。
+
+下面讨论更高级的处理方式，方案会复杂些，实现成本也略高
+
+
+[微服务调用超时处理-高级方案](https://www.jianshu.com/p/d68d572b0613)
+
+转载网友的博客，下面贴出关键点
+
+* 同步超时
+
+超时可能发生的点
+
+在同步调用的模式下，超时可能发生的节点有以下三处：
+
+请求超时，客户端给服务端发送请求时超时，此时服务端没有收到客户端的请求；
+服务端内部超时，服务端可能存在DB操作、IO操作、调用其他服务超时；
+响应超时，服务端给客户端返回响应时超时，此时服务端已经处理了请求。
+
+### 客户端
+无论是何种超时，对于客户端来说都是透明的，即客户端无法知道具体发生超时的点。客户端对于超时的处理，有如下两种常见方法：
+
+  * 查询，通过主动查询去拉取超时请求的状态。这种方法需要服务端提供查询接口，并且是根据客户端生成的请求流水号作为查询的条件，因为同一个服务或者接口可能会存在多个调用方，这就需要服务端能够唯一标识某一个客户端请求。
+
+
+如何唯一标识客户端请求，有以下两种方案可供参考.
+1. 全局流水号（traceId），全局流水号需要在所有调用方之间唯一，这可能需要在全公司层面有分布式发号器的应用。
+2. 如果在调用方的应用有不属于公司的应用，那么全局流水号可能就不好控制了，这个时候可以使用：productId+productSeqId的组合形式。productId表示接入方的系统号，productSeqId表示接入方的流水号，productSeqId需要保证在同一个productId内是唯一的。这样服务端就可以通过productId + productSeqId来唯一标识客户端的请求。
+
+
+  * 重试，需要设置重试梯度（5s,30s,1min...），以及重试次数的阈值(最多重试的次数)。另外，客户端的重试需要服务端支持幂等（多次执行和只执行一次的效果一样）。
+
+### 服务端
+对于①.请求超时和③.响应超时服务端是无法感知的，也就没法进行处理。而在②.服务端内部超时时服务端应该快速失败，立即响应客户端。如果是服务端调用其他服务(例如，服务C)超时，服务端除了快速失败之外，还需要调用服务C的冲正操作。
+
+
+
+
+
+服务端内部调用其他服务超时
+
+服务C的冲正接口需要能够判断之前是否接收过服务端超时的请求，如果接收过请求并做了处理，则应该执行反向的回滚操作，如果没有接收过，则忽略冲正请求。
diff --git a/readme/hashmap-memory-leak.md b/readme/hashmap-memory-leak.md
@@ -1,6 +1,6 @@
 # 使用HashMap的时候如何避免内存泄漏
 
-当Key为复杂类型（自定义对象)的时候，如果map.put(obj, value)后
+当HashMap的Key为复杂类型（自定义对象)的时候，如果map.put(obj, value)后
 如果修改了obj中的某些字段值，而且这这个字段会导致obj.hashCode()发送变化的。就必定导致内存泄漏。
 因为Node数据的存放地址没变，但是里面的key变了。 
 
