记一个Spring Data JPA自定义分页查询BUG
官方给出的自定义分页查询的示例是这样的:
1 | public interface UserRepository extends JpaRepository<User, Long> { |
官方给出的自定义分页查询的示例是这样的:
1 | public interface UserRepository extends JpaRepository<User, Long> { |
Stream在执行intermediate(例如 map、filter)操作时,会形成referencePipeline 双向链表。
TermianlOp执行时遍历链表:
1 | for ( AbstractPipeline p=AbstractPipeline.this; p.depth > 0; p=p.previousStage) { |
执行StatelessOp 中Sink的OnWrapSink。
(通过Sink 中ChainedReference 翻转)
所以Stream中的元素是依次应用intermediate操作。并不是所有元素应用完第一个intermediate操作,在应用下一个。
PS:使用Stream时,首先会构建一个HEAD-源阶段(Stream()),然后经历StatelessOp-中间阶段(map、filter),最终通过TermianlOp(reduce等)
在Java中什么样的对象会被回收呢?
数据ID生成方案中UUID相对来说是最简单的,但是其也有不少缺点:
1.没有排序,无法保证趋势递增。
2.UUID往往是使用字符串存储,查询的效率比较低。
3.存储空间比较大,如果是海量数据库,就需要考虑存储量的问题。
4.传输数据量大
5.不可读。
常见优化方案:
1.优化字符串为BigInteger
1 | private static BigInteger pair() { |
2.去掉符号:
1 | private static BigInteger pair(UUID uuid) { |
在做性能测试时,需要确保输入参数是确定的,否则处理参数还会带来一定的性能损耗。
JVM主要接受两类标志(少数例外):布尔标志和附带参数标志。
-XX:+FlagName
表示开启,-XX:-FlagName
表示关闭。-XX:FlagName=something
。例如-XX:NewRadio=N
。HashMap 默认有一个初始大小(initialCapacity),这个初始大小是16。
在各种开发规范手册中都可以看到会建议设置这个大小。
例如:new HashMap(3);
那么我们设置了初始容量为3,HashMap的容量真的会初始化为3了吗?
答案是否定的。
为了提高Hash效率,Java中会重新计算这个值,获得一个>3的最小2的N次方,大于3的最小2的N次方就是4(关于为什么请参照
https://www.zhihu.com/question/28562088/answer/111668116)。
这个4是怎么来的呢?
废话少说,直接上代码: