Java面试复习大纲
2021-02-01 14:08:08   4  举报             
     
         
 AI智能生成
  Java面试复习大纲
    作者其他创作
 大纲/内容
  Zookeeper    
     选举机制  
     过半机制  
     预提交 ack 2pc  
     Dubbo    
     Netty    
     零拷贝  
     BIO    
     阻塞 IO 读写都阻塞  
     问题 带宽 资源等  
     每个请求过来 开一个线程阻塞  
     NIO    
     不阻塞来者不拒  
     但是可能等待的时间太久相应延迟大了 太短了 会重试  
     通道 buffer 多路复用    
     监听事件  
     AIO  
     架构设计思路  
     执行链路    
     初始化channel  
     注册channel到selector    
     任务队列  
     轮训accept事件 处理这些简历 channel的链接  
     注册 channel到selector接收方  
     轮训写 事件 开线程去处理    
     任务队列  
     线程组    
     boss    
     监听端口所有准备就绪时间  
     work    
     监听准备工作  
     调用链路  
     服务暴露过程    
     IOC启动加载dubbo配置的标签  
     解析标签ServiceBean会生成一个Bean  
     实现了InitializingBean
    
     afterpropertiesSet    
     get provider  
     set provider  
     各种信息 保存在 Serviceean  
     IOC完成 还实现了一个ApplicationListener监听器    
     回调onaoolicationEvent    
     是否暴露不是延迟暴露  
     暴露    
     信息校验doexport    
     检查  
     doexportURL暴露URL    
     加载注册中心信息  
     循环协议 端口    
     代理工厂获取 invoke封装    
     暴露invoke    
     根据spl来  
     本地暴露  
     打开服务器 exchangeService  
     启动服务器netty 监听服务  
     注册中心 注册服务    
     注册表    
     执行器  
     暴露 p和s 两个invoke的map缓存保存了地址  
     spl  
     服务引用    
     factoryBean->getObject->get    
     init  
     信息检查    
     创建代理对象 createProxy  
     远程引用 获取zk 获取信息 订阅    
     dubbo执行远程引用  
     创建netty客户端    
     返回invoke    
     注册到注册表进去  
     成功  
     SPL    
     java spl    
     Java 没 ioc aop  
     具体的spi kv形式    
     静态代理  
     容错机制    
     failover    
     直接切换  
     failfast    
     快速失败  
     failback  
     forking cluster  
     broadcast cluster  
     整合 hystrix    
     失败回调  
     返回默认  
     降级    
     return null  
     失败返回空  
     负载均衡    
     随机 加权  
     轮训  
     最少活跃数  
     hash 一致  
     选举算法  
     注册中心  
     协议    
     dubbo    
     默认 nio 单一长链接  
     二进制系列化 小数据量 100k  
     数据量中等 不适合文件传输  
     memcached  
     redis  
     webservice  
     http  
     RocketMQ    
     基础组成    
     NameService    
     无状态模式  
     brock 向发心跳顺便带上所有的Topic 信息  
     早期是zk后来改动  
     Brocker    
     中转消息,消息持久化  
     底层通信基于Netty  
     Producer    
     同步  
     异步  
     单向  
     Consumer    
     pull  
     push  
     支持集群模式    
     多master  
     多master多slave异步复制  
     多master多slave双写  
     消费保证    
     发送成功后返回consume_success  
     回溯消息  
     高可用    
     集群    
     NameService集群  
     Broker主从 双主 双从  
     Cosumer 自动切换  
     producer 链接两个Broker  
     刷盘    
     同步 超时会返回错误  
     异步 不返回  
     消息的主从复制    
     同步复制  
     异步复制  
     主从同步    
     异步刷盘  
     消息数顺序    
     Hash取模    
     RocketMQ提供了MessageQueueeSelector队列选择机制    
     顺序发送 顺序消费 消费者保证    
     消费者是多线程  
     消息去重    
     幂等  
     去重    
     消息表主键冲突  
     分布式事务    
     最大努力    
     消息表 不断轮训 人工干预  
     半消息    
     发送半消息 发送成功 本地事务 觉得是否提交还是回滚 服务端收到回复 检查本地事务 根据本地事务决定 提交  
     2/3pc  
     最终一致    
     预发 持久化 返回状态 发送处理结果 判断是否干掉持久的 发送  
     完整的一个调用链路    
     producer 和 NameService 节点建立一个长链接  
     定期从NameService获取Topic信息  
     发送消息给Broker Master  
     consumer 从 salve一起订阅  
     消息重试    
     顺序消息重试    
     不断重试 16次 4小时 46分钟 可以修改尝试次数  
     对一个消费者设置 组内都会设置  
     可以获取消息重试次数  
     无序消息重试  
     死信队列    
     不再被正常消费  
     保存3天  
     面向消费者消费  
     控制台 重发 重发消费者 单独消费者  
     事务消息  
     消息积压    
     决定是否丢弃  
     判断吞吐量  
     停止消费 加机器 加topic  
     分布式锁    
     Zookeeper    
     死锁  
     羊群效应  
     临时节点顺序  
     性能没redis高  
     Redis    
     jedis.set(String key, String value, String nxxx, String expx, int time))  
     性能比较高  
     数据库    
     死锁    
     设置一个失效时间用定时任务去跑  
     数据库集群 主备同步‘’搞个死循环排队  
     可重入设计一个字段累加  
     排它锁    
     用数据库自身锁就可以 行锁 索引  
     select xx for update  
     记得提交  
     宕机数据库也会自动释放锁  
     缺点    
     比其他的更耗费资源  
     复杂  
     特点    
     互斥  
     安全性  
     死锁  
     容错  
     算法    
     贪心  
     分治  
     动态规则  
     快排  
     堆排  
     二叉树  
     链表反转  
     成环  
     环节点  
     跳楼梯  
     扩展知识    
     内存屏障  
     指令乱码  
     分支预测  
     NUMA  
     CPU亲和性  
     踩过的坑    
     sync遇到了 bgsave    
     CPU飙升    
     bgsave之后会做一个emptyDB    
     这个时候做bgsave cow的机制就没了    
     这个时候做bgsave cow的机制就没了    
     会重新加载整个RDE    
     然后就save  
     高并发场景下无限同步    
     tps过高的时候    
     master复制缓存挤压区的时候 有个参数client-output-buffer-limit默认1M    
     大量请求会让值高升 超出阈值断开    
     重连  
     slave做RDB同步的时候回导致TPS过高无法加载    
     阻塞久了复制缓冲区的数据被冲掉了,是个队列会踢掉之前的数据    
     slave重连对比offset发现空挡重新sync    
     预估体量参数动态调整  
     canal并发修改  
     es自动机构建  
     redis es 深分页  
     集合    
     HashMap    
     1.7    
     数组+链表  
     头插  
     1.8    
     数组+链表+红黑树  
     尾插  
     扩容机制    
     LoadFactory(加载因子)默认0.75  
     创建一个空数组重新Hash    
     Hash公式和长度有关  
     线程不安全  
     2的幂次方    
     segment分段锁    
     继承了reentrankLock  
     尝试获取锁并发竞争 自旋 阻塞  
     方便运算  
     均匀分布  
     重写equals必须重写HashCode  
     ConcurrentHashMap    
     1.7    
     数组+链表  
     get高效 volatile修饰 不需要加锁  
     volatile修饰节点指针  
     HashEntry  
     1.8    
     数组+链表+红黑树  
     CAS+synchronized    
     cas失败自旋保证成功    
     再失败就sync保证  
     node  
     安全失败  
     ArrayList    
     数组  
     查找 访问速度快 增删效率低 线程不安全  
     LinkedList  
     基础    
     UDP    
     语音  
     视频  
     直播  
     TCP    
     三次握手    
     syn seq  
     syn ack seq  
     为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误  
     四次挥手    
     fin ack seq  
     ack seq fin ack seq  
     ack seq  
     场景    
     网络回话  
     文件传输  
     发送接收邮件  
     远程登录  
     如何保证可靠  
     HTTP  
     HTTPS    
     为什么安全  
     BIO    
     阻塞等待链接  
     阻塞等待数据  
     开线程处理并发  
     耗资源  
     NIO    
     非阻塞IO  
     epoll  
     粘包/拆包    
     在报文末尾增加换行符表明一条完整的消息,这样在接收端可以根据这个换行符来判断消息是否完整。将消息分为消息头、消息体。可以在消息头中声明消息的长度,根据这个长度来获取报文。规定好报文长度,不足的空位补齐,取的时候按照长度截取即可。  
     多路复用    
     select    
     单个进程可监视的fd数量被限制,即能监听端口的大小限制。  
     对socket进行扫描时是线性扫描,即采用轮询的方法,效率低下。  
     poll    
     大量的fd的数组被整体复制于用户态和内核地址空间之间,而不管这样的复制是不是有意义。  
     poll还有一个特点是“水平触发”,如果报告了fd之后,没有被处理,那么下次这样的复制是不是有意义。  
     epoll    
     没有最大并发连接的限制,能打开的FD的上限远大于 1024(1G的内存上能监听约10万个端口)  
     效率提升,不是轮训的方式,不会随着FD目的增加效率下降。  
     内存拷贝,利用mmap()文件映射内存加速与内核空间的消息传递;即epoll使用mmap减少复制开销。  
     netty 非异步 阻塞 response trse id 感觉  
     序列化  
     多线程    
     synchronized    
     对象    
     对象头(Header)    
     Mark Word (存储对象的HashCode,分代年龄和锁标志位信息)  
     Kiass Point(对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象杀死那个类的实例)  
     Monitor    
     EntryList  
     Owner(会指向持有Monitor对象的线程)  
     WaitSet  
     实例数据  
     对其填充  
     方法    
     ACC_SYNCHRONIZED  
     代码块    
     monitorenter
  
     monitorexit  
     程序计数器 count    
     加减  
     锁膨胀    
     偏向->轻量级(乐观)->自旋->重量级    
     6  
     ThreadLocal    
     内存泄露  
     session  
     Lock    
     ReentrantReadWriteLock    
     ReadLock  
     WriteLock  
     ReentrantLock
    
     NonfairSync    
     tryAcquire  
     acquireQueued  
     CAS  
     FairSync
    
     hasQueuedPredecessOrs  
     如果是当前持有锁的线程可重入  
     AbstractQueuedSynchronizer    
     入队 出队  
     头结点设计  
     共享和独享的实现  
     CAS    
     实际应用  
     存在的问题    
     cpu开销  
     只能保证一个共享变量原子操作    
     AtomicReference  
     ABA  
     StarmpeclLock
  
     volatile    
     MESI    
     当CPU写数据时,如果发现操作的变量是共享变量,即在其他CPU中也存在该变量的副本,会发出信号通知其他CPU将该变量的缓存行置为无效状态,因此当其他CPU需要读取这个变量时,发现自己缓存中缓存该变量的缓存行是无效的,那么它就会从内存重新读取  
     锁bus  
     volitale会一直嗅探 cas 不断循环无效交互 导致带宽达到峰值    
     总线凤暴  
     Java内存模型JNIM    
     高速缓存  
     可见性    
     嗅探机制强制失效    
     处理器嗅探总线  
     有序性    
     禁止指令重排    
     lock前缀指令内存屏障    
     源代码->编译器优化重排序->指令级并行重排序->内存系统重排序->最终执行的指令序列  
     happens-before    
     volatille变量规则:对一个volatile域的写,happens-before于任意后续对这个volatile域的读。  
     as-if-serial  
     Atormiclntegcr  
     跳出死循环  
     线程池    
     neeFiedThreadPooll
  
     newCacheThreadPool
    
     SpnchronousQueue  
     newSlngle TheadExecutor
  
     newscheduledThewadPool
    
     DelayedWorkQueue  
     neeorkStealingPool
  
     ThreadPoolExecutor  
     参数意义    
     核心线程数    
     默认没线程等任务来了才调用了 预创建线程 一个或者全部  
     最大线程数  
     空闲时间&单位    
     没有执行任务多久会终止 当线程池的线程数大于核心线程才会起作用 调用allowCoreThreadTimeOut会起作用  
     缓冲队列    
     LinkedElockingGueue
    
     无界 当心内存溢出  
     ArrayBlockingQueue
    
     有界队列  
     加锁保证安全  一直死循环阻塞  队列不满就唤醒  
     入队    
     阻塞调用方式put(e)或 offerle, timeout, unit)
阻塞调用时,唤醒条件为超时或者队列非满(因此,要求在出队时,要发起一个唤醒操作)进队成功之后,执行notEmpty.signail()唤起被阻塞的出队线程
  
    阻塞调用时,唤醒条件为超时或者队列非满(因此,要求在出队时,要发起一个唤醒操作)进队成功之后,执行notEmpty.signail()唤起被阻塞的出队线程
 在进行某项业务存储操作时,建议采用offer进行添加,可及时获取boolean进行判断,如用put要考虑阻塞情况《队列的出队操作慢于进队操作),资源占用。  
     Synchronous  
     工厂方法  
     拒绝策略    
     抛异常  
     丢弃  
     重试  
     丢弃最早提交的  
     使用Hash表维护线程的引用  
     submit    
     使用future获取任务的执行结果  
     实际使用    
     商品详情界面  
     批处理  
     执行过程    
     核心线程->队列->最大线程->拒绝策略  
     运行状态    
     有个Volatile的状态码    
     running  
     shutdown  
     stop  
     terminated    
     所有线程销毁  
     corePoolSize、maxilimumPoolSize、largestPoolSize有意思
  
     故障  
     JUC  
     常见问题    
     线程间是怎么通讯的?    
     wiat/notify机制,共享变量的synchronized或者Lock同步机制  
     volatile  
     CountDownLatch  
     CyclicBarrier  
     ThreadLocal 用来解决什么问题?    
     减少临界范围,使用ThreadLocal,,减少线程切换、使用读写锁copyonwriter等机制这些方法  
     如何尽可能提高多线程并发性能?    
     ThreadLocal是如何实现的?重点回答ThreadLocal不是用来解决多线程共享变量的问题,而是用来解决线程数据隔离  
     对写锁适用于什么场景?    
     读写锁适合读并发多,写并发少的场景,另外一个解决这种场景的方法是copyonwriter  
     如何实现一个生产者与消费者模型?    
     可以尝试通过锁、信号量、线程通信、阻塞等不同方式实现。  
     线程状态    
     线程就绪    
     start  
     sleep休眠超时  
     countDownLatch    
     只有一个构造方法 只会被赋值一次  
     没有别的方法可以修改count  
     JVM    
     JVM内存模型    
     堆  
     栈  
     方法区  
     本地方法栈  
     程序计数器  
     类加载机制    
     加载->验证->准备-.解析->初始化->卸载  
     双亲委派机制    
     父类加载 不重复加载  
     分代回收    
     老年代  
     新生代  
     永久代/元空间  
     晋升机制    
     根据存活时间  
     垃圾回收期    
     CMS    
     分代    
     年轻代    
     eden  
     S1  
     S2  
     minor gc    
     通过阈值晋升  
     老年    
     minor gc 的等价于full gc  
     永久  
     缺点    
     对CPU资源敏感  
     无法处理浮动垃圾  
     基于标记清除算法 大空间碎片  
     G1    
     分区概念 器化分代  
     标记整理算法 不会产生空间碎片 分配大对象不会提前full gc  
     可以设置预停顿时间  
     充分利用CPU 多核条件下 缩短 stw  
     收集步骤    
     初始标记 stw 从 gc root 开始直接可达的对象  
     并发标记 gc root 对对象进行可达性分析 找出存活对象    
     可达性分析算法  
     最终标记  
     删选回收    
     根据用户期待的gc 停顿时间制定回收计划  
     回收模式    
     young gc    
     回收所有的eden s区    
     复制一些存活对象到old区s区  
     mixed gc  
     GC模式  
     区别    
     g1分区域,每个区域是有老年代概念的 但是收集器以整个区域为单位收集  
     g1收集后马上合并空间内存 cms在stw的时候做  
     内存区域设置    
     XX:G1HeapReginonSize  
     复制成活对象到一个区域 暂停所有线程  
     垃圾回收机制    
     标记清除    
     试用场景    
     对象存活比较多的时候试用  
     老年代  
     缺点    
     提前GC  
     碎片空间  
     扫描了两次    
     标记存活对象  
     清除没有标记对象  
     标记复制    
     试用场景    
     存活对象少 比较高效  
     扫描了整个空间(标记存活对象并复制异动)  
     适合新生代  
     缺点    
     需要空间空闲  
     需要复制移动对象  
     引用计数    
     没办法解决循环引用问题  
     标记整理  
     full gc    
     老年代写满  
     system.gc  
     持久代空间不足  
     STW  
     实战    
     性能调优    
     设置堆的最大最小值 -xms -xmx  
     调整老年代和年轻代的比例    
     -XX:newSize设置绝对大小    
     防止年轻代堆收缩:老年代同理  
     主要看是否存在更多持久对象和临时对象  
     观察一段时间 看峰值老年代如何 不影响gc 就加大年轻代  
     配置好的机器可以用 并发收集算法  
     每个线程默认会开启1M的堆栈 存放栈帧 调用参数 局部变量 太大了 500卡足够  
     原则 就是减少gc stw  
     FullGC内存泄露排查    
     jasvism  
     dump  
     监控配置 自动dump  
     com种类  
     逃逸分析  
     可达性    
     虚拟机栈(栈帧中的本地变量表)中引用的对象  
     方法区中常量静态属性引起的对象  
     方法区中常量变量引用的对象  
     本地方法栈中JNI(即一般说的Native方法)引用的对象  
     活跃线程的引用对象  
     JVM调优    
     OCM  
     内存泄露  
     锁征用  
     Java进程消耗CPU过高  
     JVM性能检测工具    
     Jconsole  
     Jprofiler  
     jvisualvm  
     MAT  
     内存泄露    
     help dumo  
     生产机 dump  
     mat  
     jump  
     -helpdumop  
     CPU100%    
     topc -c  
     top -Hp pid  
     jstack    
     进程转换  
     cat  
     Spring    
     设计模式    
     单例  
     多例  
     适配器    
     根据不同商家适配  
     责任链    
     继承 process 链路执行  
     源码  
     Bead    
     生命周期    
     扫描类    
     linvokeBeanFactoryPostProcessors
  
     封装beanDefiniton对象 各种信息  
     放到map  
     遍历map  
     验证    
     能不能实例化 是否需要实例化需要根据信息来  
     是否单例等等  
     单丽池 只是一个ConcrurrentHahsMap  
     正在创建的 容器  
     得到class  
     推断构造方法    
     根据注入模型  
     默认  
     得到构造方法  
     反射 实例化这个对象  
     后置处理容器合并beanDefinintion  
     判断是否允许 循环依赖  
     提前暴露bean工厂对象  
     填充属性    
     自动注入  
     执行部分aware接口  
     继续执行部分aware 接口 生命周期回调方法  
     完成代理AOP  
     baenProstprocecssor 的前置方法  
     实例化为bean  
     放到单例池  
     销毁  
     作用域    
     单例(singleton)  
     多例(prototype)  
     Request  
     Session  
     循环依赖    
     情况    
     属性注入可以破解  
     构造器不行    
     三级缓存设自己 因二级之后去加载了  
     三级缓存    
     去单例池  
     判断是不是正在被创建的  
     判断是否支持依赖  
     二级缓存 放到 三级缓存  
     干掉二级缓存    
     GC  
     下次再来直接 三级缓存拿 缓存  
     缓存 存放    
     一级缓存 单例 Bean  
     二级缓存 工厂 产生Bean    
     产生Bean 复合  
     三级缓存 半成品  
     父子容器  
     事务实现原理    
     采用不同的容器  
     用AOP新建立了一个连接    
     共享链接  
     ThreadLocal 当前事务  
     前提是 关闭AutoCommit  
     AOP    
     静态代理    
     实现类  
     动态代理    
     JDK动态代理    
     实现接口    
     Java反射机制生成一个代理接口的匿名类    
     调用具体方法的时候调用invokeHandler  
     cjlib    
     asm字节码编辑技术创建类 基于classLoad装载    
     修改字节码生成子类处理  
     IOC  
     类加载机制    
     过程    
     加载    
     生成一个class对象  
     验证    
     文件格式验证  
     元数据验证  
     字节码验证  
     符号引用验证  
     准备    
     默认值  
     static会分配内存  
     解析    
     解析具体类的信息    
     引用等  
     初始化    
     父类没初始化 先初始化父类  
     使用  
     卸载  
     加载方式    
     main()  
     class,forName  
     ClassLoader,loadClass  
     类加载器    
     AppClass Loade  
     Extention ClassLoader  
     Boorstrap ClassLoader  
     双亲委派机制    
     可以避免重复  
     安全  
     Redis    
     数据结构    
     String  
     Hash  
     set  
     zset    
     score  
     随机底层    
     只需要调整前后节点指针  
     不止比较score    
     还会比较value  
     场景    
     成绩  
     积分  
     排行榜  
     List    
     注意分页的坑  
     HyperLogLog  
     Geo  
     Pub/Sub  
     BitMap  
     底层    
     SDS    
     保存键值  
     AOF缓存区  
     记录本身长度 C需要遍历  
     修改重新分配    
     空间预支配  
     惰性空间释放  
     二进制安全  
     链表    
     保存多个客户端的状态信息  
     列表订阅发布 慢查询 监视器  
     字典    
     Hash表  
     Hash表节点  
     Hash算法 索引值  
     渐进式rehash  
     每个字典带两个hash表  
     压缩列表  
     整数集合  
     常见命令    
     Keys  
     setnx  
     exprle  
     高可用    
     持久化    
     RDB    
     5分钟一次  
     冷备  
     恢复的时候比较快  
     快照文件生成时间  
     AOF  
     数据初始化    
     从节点发送命令主节点做bgsave同时开启buffer  
     数据同步机制    
     主从同步    
     指令流    
     offset  
     快照同步    
     RDB    
     缓冲区  
     哨兵    
     集群监控  
     消息通知  
     故障转移  
     脑裂  
     集群    
     链表  
     多主    
     横向扩容  
     多片  
     常见问题    
     缓存雪崩    
     加随机值  
     集群部署  
     缓存击穿    
     互斥锁  
     热点数据不失效  
     缓存穿透    
     布隆过滤器  
     双写一致性    
     延时双删  
     并发竞争    
     分布式锁  
     大key    
     bigkey命令 找到删除  
     Redis 4.0引入了 memory usage命令和lasyfree机制  
     热点key    
     缓存时间不失效  
     多级缓存  
     布隆过滤器  
     读写分离  
     过期策略    
     定时删除    
     消耗内存    
     创建一个定时器  
     惰性删除    
     可能存在大量key  
     定期删除    
     检查 删除 但是是随机的  
     淘汰机制    
     LUR    
     最少使用  
     备用方案    
     主从+哨兵+cluster  
     ecache+Hystrilx+降级+熔断+隔离  
     持久化  
     限流    
     setnx ex  
     zset    
     窗口滑动  
     zset会越来越大  
     令牌    
     定时push  
     然后leftpop  
     问题    
     空轮训    
     bipop    
     空连接异常    
     重试  
     漏桶 funnel    
     make_space 灌水之前调用漏水 腾出空间 取决于流水速率    
     Hash    
     原子性问题    
     Redis-Cell  
     redis cell  
     选择方案    
     热点key    
     二级缓存  
     备份热点key走不同的机器  
     扩展    
     跳跃表  
     令牌  
     漏桶  
     scan  
     多路IO复用    
     redis得读到很多才返回为0 会卡在那 直到新数据来或者链接关闭  
     写不会阻塞除非非阻塞区满了  
     非阻塞的IO提供了一个选项no_biocking 读写都不会阻塞 读多少写多少 取决于内核的套接字字节分配  
     非阻塞IO也有问题 线程要读数据 读了一点就返回了 线程什么时候知道继续读写一样  
     一般都是select解决 但是性能低 现在都是epoll  
     MySQL    
     分库分表    
     唯一主键  
     事务隔离级别    
     读未提交  
     读已提交  
     可重复读  
     序列化  
     回滚日志    
     没更早的read view删除    
     5.5之前回滚删除了文件也不会变小  
     索引    
     B+  
     Hash    
     等值查询  
     优化流程    
     预跑sql  
     排除 缓存 sql nocache  
     看下一行数对不对 不对可以用analyze table 矫正  
     添加索引 索引不一定是最优的 force index 强制索引 不建议用  
     存在回表的情况  
     覆盖索引避免回表,不要*  
     联合索引 不能无限速 高频场景  
     最左前缀原则 按照索引定义的字段顺序写sql  
     合理安排联合索引的顺序  
     5.6之后 索引下推 减少回表次数  
     聚簇索引  
     非聚簇索引    
     多扫描一次    
     减少回表  
     索引维护    
     页满了 页分裂 页利用率下降  
     数据删除 页合并  
     自增 只追加可以不考虑 也分页  
     索引长度  
     索引选择    
     普通索引    
     找到第一个之后 直到朋友不满足的  
     唯一索引    
     找到第一个后不满足就停止了  
     页的概念  
     更新    
     change buffer  
     更新操作来了 如果页不存在 就缓存下来 下次来了 更新 在就直接更新  
     唯一索引 需要判断 所以 用不到change buffer  
     innodb的处理流程    
     记录在页内    
     存唯一索引 判断没冲突插入   
     .普通索引 插入  
     记录不在页中    
     .数据页读入内存 判断 插入  
     change buffer  
     数据读是随机IO 成本高  
     机械硬盘 change buffer 收益大 写多读少 marge  
     MVCC    
     成本链 在聚餐索引中 有两个隐藏列 trx_id roll_pointer  
     读未提交    
     直接读取最新版本  
     序列化    
     加锁  
     Read View    
     读已提交    
     每次读取前生成一个  
     可重复读    
     第一次生成一个  
     锁    
     全局锁    
     全库逻辑备份  
     表锁    
     lock table read/write  
     读锁不互斥 写锁互斥  
     行锁    
     需要的时候才加上并不是马上释放 等事务结束才释放 两阶段锁协议  
     死锁    
     超时时间    
     innodb_lock_wait_timeout  
     死锁机制 事务回滚    
     innodb_deadlock_delet=on  
     热点行    
     CPU    
     临时关闭  
     控制并发度  
     分治  
     间隙锁  
     读写锁    
     读    
     lock in share mode  
     for update  
     行锁  
     写  
     innodb如何加锁    
     Record lock:对索引项加锁。
  
     Grap lock:对索引项之间的"间隙",第一条记录前的间隙,或最后一条记录的间隙 加锁。  
     Next-key:前的两种组合。对记录及前面的间隙加锁。  
     B+  
     log    
     udo log    
     回滚 mvcc  
     redio log  
     binlog  
     两段式提交 redo 准备 binglog 提交  
     主备延迟    
     强制走主  
     sleep  
     join    
     驱动表  
     id用完    
     bigInt  
     row_id(没设置主键的时候)  
     thread_id  
     真实故障    
     数据库挂了 show processlist 一千个查询在等待 有个超长sql kill 但是不会引起fiush table 但是不会引起flush   table 脚本优化 analize会导致MySQL监测到对应的      table作了修改 必须flush close reopen就不会释放表的占用  
    
 
 
 
 
  0 条评论
 下一页