如果看过 JDK 8 中 ArrayList 的源码,你会发现存在如下代码 ArrayList.java at jdk8-b120:
1 | /** |
如果看过 JDK 8 中 ArrayList 的源码,你会发现存在如下代码 ArrayList.java at jdk8-b120:
1 | /** |
在业务中曾有为不同的 key 的操作实现锁语义的需求,常见的实现为构建一个线程安全的 Map 实现然后为每个 key 创建对应的对象用于互斥锁,但是该实现存在内存泄漏的问题,即随着不同 key 不停地出现,该 Map 实例会越来越大,之前为每个 key 创建的对象一直驻留在内存中,即使 key 永远不再出现。比如 JDK 7 引入的支持并行类加载的特性 Multithreaded Custom Class Loaders in Java SE 7 中,引入了如下代码:
1 | // Maps class name to the corresponding lock object when the current |
本文主要记录 JDK 12 中 ConcurrentHashMap 的扩容实现。首先需要关注的为 sizeCtl 变量,其定义如下:
1 | /** |
我们发现在部分实例上采集的 CPU 使用率明显不正确,出问题时采集到的值总是高于实际值,进入实例通过 top 等命令确认 CPU 使用率并不高,且有时重启应用后采集的 CPU 使用率又会正常,再次重启后可能又不正常,其中一台单核 CPU 实例的 CPU 使用率不正常时的 Grafana 监控图表如下图所示:
一直以为 max-age 设置的值表示本地浏览器接收到响应后从当前时刻开始计算的可存活的时间,今天查了个问题,发现并不是。根据 RFC 中的描述,max-age 表示自源站服务器端生成响应后的最大生存时间,并不是自本地浏览器接收到响应后的最大生存时间。
A response’s age can be calculated in two entirely independent ways:
- now minus date_value, if the local clock is reasonably well synchronized to the origin server’s clock. If the result is negative, the result is replaced by zero.
- age_value, if all of the caches along the response path implement HTTP/1.1.
Given that we have two independent ways to compute the age of a response when it is received, we can combine these as
corrected_received_age = max(now - date_value, age_value)and as long as we have either nearly synchronized clocks or all HTTP/1.1 paths, one gets a reliable (conservative) result.
同时发现对没有设置 Cache-Control 的资源,浏览器对部分资源进行了 If-Modified-Since 探测,而部分资源没有进行探测直接使用了本地缓存,查了下文档,原来是根据资源的 Last-Modified 距当前时间的差值来决定是否缓存一段时间,简单来说就是如果一个资源上次修改的时间已经很久了,那么我们可以认为在一定时间段内,该资源不会被修改,所以这时即使没有设置 Cache-Control,浏览器也会将该资源缓存一段时间。典型的缓存时间计算公式为 (current time - last modified time) / 10。