weixin_55415722的博客

需求从数据库查询所有元素，并分页显示在界面上实现创建分页页面对象/** * 封装分页相关的信息. */public class Page { // 当前页码 private int current = 1; // 显示上限 private int limit = 10; // 数据总数(用于计算总页数) private int rows; // 查询路径(用于复用分页链接) private String path;

并发条件下HashMap的死循环问题HashMap的容量是有限的。当经过多次元素插入，使得HashMap达到一定饱和度时，Key映射位置发生冲突的几率会逐渐提高。这时候，HashMap需要扩展它的长度，也就是进行Resize。发生Resize的条件HashMap的元素的个数 >= 数组容量 x 负载因子步骤：1、扩容创建一个新的空数组，长度为原数组的2倍2、rehash遍历原Entry数组，把所有的Entry重新Hash到新数组。rehash代码/** * Transfers a

自适应哈希索引（AHI）问题背景众所周知，Innodb存储引擎索引底层数据结构是B+树，而B+树查找的时间复杂度取决于B+树的高度。而有一种数据结构，它查找的时间复杂度是O（1），那就是——数组。想到数组，进而联想到哈希（hash）查找方法。因此，Innodb存储引擎在B+树索引的基础上，又引入了自适应哈希索引来提高查找效率。解决方案Innodb会监控对表上各个索引页的查询，如果观察到建立Hash索引可以带来速度提升，则建立哈希索引，又称为自适应哈希索引（AHI）。AHI是通过缓冲池中的B+树页构

【MySQL】Innodb特性之——double write问题背景当数据库发生宕机时，Innodb可能正在把内缓冲区中的脏页写到表中，此时假如一个页只写了一部分，则出现部分写失效问题。Innodb使用双写机制（double write）解决部分写失效导致的数据丢失问题。解决方案有人会想到可以通过重做日志恢复，但是，重做日志中记录的是对页的物理操作，但如果页本身已经损坏，则重做日志不再起作用。这时，在应用重做日志之前，可以copy一个页的副本，先用副本重放日志，进行重做，这就是双写机制。内部实现

目录问题背景解决方案使用条件：存在问题：升级：内部实现：Insert Buffer Bitmap合并过程问题背景在Innodb存储引擎中，主键是行唯一标识符，并且对数据的插入和读取是按页进行。行记录按主键顺序插入效率会非常高，因此插入聚集索引一般是磁盘的顺序插入，不需要随机读取。如果表存在主键a（自动增长），对a列的插入NULL，页中数据都是按a的值顺序存放，则不需要随机读取另一个页的记录，因此效率很高。不是所有的主键插入都是有序的，例如主键是uuid这

为什么会出现？在企业级应用开发过程中，传统的开发上线流程是程序员将代码打成war/jar包，交由运维工程师进行部署上线。但这样存在一个问题，就是运维程序员本地的环境可能与开发工程师本地环境不一致，导致在开发工程师本地可以正常运行的程序在运维工程师本地不可以正常运行。因此，可以考虑是否可以把程序连同环境一起“打包”，这样一个“包”就可以在任意机器上运行，而不需要运维工程师进行环境配置，即“软件带环境安装”。于Docker虚拟化技术应运而生。定义一句话，Docker是解决了运行环境和配置问题