面试记录 总结 问题 .txt

分布式事务
高并发
redis哨兵
zk : zookeeper
join hash(哈希连接): 大表连接查询
两张大表(百万记录行?) 将较小表t1读到内存 按照join字段c1 将表t1建立为字段c1的hash表hashTable1 之后扫描大表t2的每一行 对每一行的字段c1 到hashTable1找看有没有键为c1的
相当于扫描大表， 用扫到的字段c1的值 作为数组下标 去内存表小表中找有没有该数组元素


假设在两表都有索引的情况下 ： { 花括弧内内容为我猜测
假设扫描大表t2的每一行 该行的字段c1的值 以小表t1的索引文件来定位小表t1中的符合的行
此时由于t2各行的c1值算出来的索引值可能不一样 导致扫描t2的下一行时候 要从磁盘中读取t1索引文件的另一个部分
因此对于t2中的不同行 可能要读取t1索引文件的不同部分 从而导致主要时间消耗在读取t1索引文件上了 而导致查询很慢 而此时上面的join hash可以解决
}

spring原理: 手写简单spring大致情形
ConncurrentHashMap Lock
乐观锁 悲观锁
volatile 易失 transient 短暂的：
volatile 易失
线程变量在CPU寄存器中 主存中也有该变量 多个线程有各自的寄存器 但主存中的变量只有一个
volatile的意思是 每次都从主存中读取该变量的值 而不信赖寄存器中的值 目的是防止其他线程修改了主存变量
volatile貌似并不能实现类似 synchronized 、锁 的部分功能


synchronized 方法 代码块 差异

线程池

hash bucket/slot: hash table
hash值的目的是实现类似数组下标的能力
但实际上只能是将一些键分为一组 这个组的序号就是hash值
; user数组(表) 按照username来找到user行 hash(username)如果直接就是下标 则直接找到该user行 但不存在这样的hash函数 但是目标是这样的目标
; 所以这样的目标只能曲折到达
; hash(username)是将一些username变为一组 组编号就是hash(username)的函数值
; 虽然由组号不能直接得到下标 但是由组号得到的是一些下标 而这些下标中包含该username的下标 也就是缩小了查找范围
; 当确定了在某组中 要排查是组中的哪一个下标 就只能将该组中所有下标都看一遍 有就是有 没有就是没有了
; 所以hash函数要尽量不要出现一个组 其中含有的下标非常多 因为这没达到缩小范围的意图 也就是所说的hash函数要尽量能将username均匀的映射到不同组中去