有不少观点认为调用 System.gc()
是一个不好的习惯,当我看到 JDK 8 中 FileChannelImpl
的 map
方法实现时,其中对 System.gc()
的调用让我感到诧异。在 FileChannelImpl
中存在如下代码 FileChannelImpl.java at jdk8-b120:
1 | try { |
有不少观点认为调用 System.gc()
是一个不好的习惯,当我看到 JDK 8 中 FileChannelImpl
的 map
方法实现时,其中对 System.gc()
的调用让我感到诧异。在 FileChannelImpl
中存在如下代码 FileChannelImpl.java at jdk8-b120:
1 | try { |
开放定址法是哈希表冲突解决的一种方法,该方法通过探测未使用的数组槽来解决散列冲突。常见的探测方法包括:
这些方法的主要区别在于线性探测具有最好的缓存性能,但是对聚集敏感,虽然两次哈希的缓存性能很差,但是几乎不存在聚集的问题,平方探测介于两者之间。相比其他的探测方法,两次哈希需要更多的计算。
今天帮同事看了个问题,该问题不复杂,只是表现出来没有头绪,在此简单记录。首先发现该问题是一个空指针异常,即调用方通过 Dubbo 调用消费端提供的方法时调用方的异常仅有一个空指针异常,没有其他有价值的信息。调用方的代码简化如下:
1 | @Reference |
第 6 行将抛出空指针异常,异常栈帧如下:
1 | java.lang.NullPointerException |
今天看到 Spring 中的 ConcurrentLruCache 实现,本文简要记录。
1 | /** |
最为核心的方法即为 get
方法,其实现思路在上方增加了注释。关键点在于读锁那部分代码是允许多线程执行的,而我们又需要维护 queue
中节点的顺序,所以选用了线程安全的队列实现:ConcurrentLinkedDeque
。唯一不理解的就是对 cache
的修改操作都被写锁保护,在当前实现中 cache
由 ConcurrentHashMap
实现,是否可以更换为 HashMap
实现呢?
关于该实现,有用户提交 issue 反馈链表中的 O(n)
扫描效率低下,建议替换为 ConcurrentLinkedHashMap,详情可参考:Revisit ConcurrentLruCache implementation · Issue #26320。
spring-framework/ConcurrentLruCache.java at v5.3.14 · spring-projects/spring-framework · GitHub
Why does ConcurrentLruCache in Spring still use thread-safe maps and queues instead of ordinary maps and queues even when read-write lock are used? - Stack Overflow