zzzgd_666的博客

3.AES加解密时，会使用到Java.security.*包，即jdk security，其中使用的jar包%JAVA_HOME%/jre/lib/security/local_policy.jar和%JAVA_HOME%/jre/lib/security/US_export_policy.jar有对技术出口的限制（因为美国的出口限制，Sun通过权限文件local_policy.jar、US_export_policy.jar做了相关限制），加密只有128bit，而没有限制的则有256bit。

最近发现自己搭的一个项目返回的数据不太准确, 第一时间想到了是缓存的问题, 缓存代码如下}有个困扰我很久的问题就是allroom的evict是否生效.类似上面这个场景, 我们经常有list()方法没指定key缓存了全部数据, 以及指定了key是id缓存了单个数据, 最后我们在方法想evict过期上面两种缓存众所周知 @Cacheable 和 @CacheEvict 的使用要求其中之一就是value和key一样, 以及方法参数要一样. 因此单个的evict肯定没问题, 问题是所有的如何过期呢。

ConcurrentHashMap的jdk1.7和1.8区别整理初始化jdk1.7Segment个数HashEntry个数jdk1.8put()方法jdk1.7jdk1.8get()方法jdk1.7jdk1.8size()方法jdk1.7jdk1.8resize()方法jdk1.7jdk1.8主要区别:1.7 采用的是分段加锁, Segment(区段) + HashEntry + Unsafe1.8 撇弃了Segment, 锁的粒度细化到具体每个桶上的头结点, 并加上CAS和Synchronize加

简单总结jdk1.7HashMap扩容死循环和jdk1.8优化jdk1.7 HashMap死循环原因扩容步骤死循环总结jdk1.8的改进jdk1.8仍然存在的问题网上很多关于jdk1.7HashMap扩容死循环的博客, 但是很多都是贴了大量的代码和图, 这里只进行简单概括总结, 详细的还是需要自己看源码.jdk1.7 HashMap死循环原因首先贴代码 (这个必要的还是要贴) void resize(int newCapacity) { .... transfer(ne

利用pac4j-cas的封装，实现自定义cas校验ST、集成jwt关于pac4j-caspac4j-cas和shiro正题，代码验证ST代码关于pac4j-cas这几天一直在折腾pac4j-cas和cas的集成. 也大概了解了一下它的运作机制。首先我们配置了一堆关于cas，cas-client的相关信息我这边观察到的pac4j-cas两个关键的过滤器，io.buji.pac4j.filter.SecurityFilter和io.buji.pac4j.filter.CallbackFilter, S

一、结论首先先放出结论，根据阿里巴巴java开发规范中，第一章第五节第9点；【推荐】集合初始化时，指定集合初始值大小。说明：HashMap 使用 HashMap(int initialCapacity) 初始化， 正例：initialCapacity = (需要存储的元素个数 / 负载因子) + 1。注意负载因子（即 loaderfactor）默认为 0.75，如果暂时无法确定初始值大小...