question2

• Java中的i++线程安全问题

  • i++语句执行过程(读取i i+1 将增值加后的i赋值给之前的i 非原子性的存在线程安全性问题)
  • volatile并不能保证非原子性操作的多线程安全问题得到解决 volatile解决的是多线程间共享变量的可见性问题
  • 解决
    • synchronized
    • AtomicInteger(CAS 算法)

• Lock和synchronized区别

  • synchronized重量级锁
  • Lock是一个接口，而synchronized是Java中的关键字
  • synchronized异常释放锁 不会deadlock(忘记手工释放锁 读锁写锁交叉使用)
  • Lock可以让等待锁的线程响应中断 interrupt方法打断长事务线程
  • Lock提高独写效率锁的粒度更小 ReentrantReadWriteLock可控制读写锁
  • synchronized是非公平锁 Lock可以设置公平(队列)非公平

• ReentrantLock和synchronized可重入底层原理

  • ReentrantLock
    原子(CAS compareAndSetState)抢占锁 比较当前线程和占用锁的线程是不是一个线程如果是增加状态变量的值
  • synchronized(实现原理 monitor 对象头 monitorenter/monitorexit指令插入方法前后)
    • 底层原理
      • Synchonized是基于Monitor对象(markword中存储的是该对象的引用)(_WaitSet/_EntryList/Owner) 计数器count加1减1来实现。
      • ReentrantLock锁都会关联一个线程和一个锁状态status 锁状态是0操作获取锁 不是0 判断是不是同一个线程 是status自增1 每一次退出方法status减1
      • synchronized优化(默认是开启偏向锁和轻量级锁 可以通过参数禁用偏向锁)
        • 状态(基于对象头中的锁状态实现) 无锁->有锁 无锁->偏向锁(第一次CAS设置锁的线程id以后已经持有直接进入同步)->轻量级锁(自适应自旋上一次长增加上一次短减少)->重量级锁(操作系统mutex)

          • 偏向锁 不释放锁 适用于大概率同一个线程持有锁

          • 锁撤销(开销大)

          • 锁膨胀(多个线程来竞争锁)

          • 轻量级锁 适用于竞争锁对象的线程不多
            

          • 锁只能升不能降

        • 适应性自旋锁
        • 锁消除(不存在竞争的写法如写法错误没有用变量 Vector/StringBuffer/HashTable)
        • 锁粗化(将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁如vector每次add)
      • 实现方式
        • Synchronized 用在方法上时，在字节码中是通过方法的 ACC_SYNCHRONIZED(常量池中) 标志来隐式实现的。
        • 而代码块同步则是使用字节码指令monitorenter和monitorexit指令实现的
      • 不公平性
        • 自旋失败后挂起阻塞等待唤醒无法立刻竞争被释放的锁然而处于自旋状态的线程，则很有可能优先获得这把锁

• ConcurrentHashMap

  • get 大量的volatile count node.val,node.next
  • helpTransfer(扩容) CAS设置数组长度(SIZECTL)
  • put
    • 位置没有值CAS放进去(casTabAt->compareAndSwapObject)
    • 节点上锁synchronized(hash值相同锁链表头节点)

• HashMap

  • null元素 单独处理放到第0个位置
  • 初始容量 (存储元素个数 / 0.75) + 1
  • 扩容(长度超过threshold(阀值) = loadFactor(0.75) * capacity(初始容量(为第一个比n大的2的幂)))
    • 创建一个新的Entry空数组 长度是原数组的2倍
    • ReHash 遍历原Entry数组，把所有的Entry重新Hash到新数组
  • helpTransfer(扩容) CAS设置数组长度(SIZECTL)
  • put
    • 位置没有值CAS放进去(casTabAt->compareAndSwapObject)
    • 节点上锁synchronized(hash值相同锁链表头节点)
  • 为什么采用红黑树
    • 长度大于8的时候加快检索速度
    • 红黑树相比avl树 检索差不多平衡来二分查找 插入删除效率提高很多(不完全平衡 省去了很多没有必要的调平衡操作)

• Mysql事务隔离级别

  • 读未提交 脏读 不可重复读 幻读
  • 读已提交 不可重复读 幻读
  • 可重复读 幻读(两次读不一致 当前读是最新数据 快照读是事务内数据)
  • 串行化

• atomikos底层实现

  • @Transactional(transactionManager = “xatx”)
  • XA规范主要定义了全局事务管理器和局部资源管理器之间的接口 主流关系型数据库实现XA XA接口是双向的系统接口

• Seata底层

  • 的服务管理事务 异步事务
  • 异常需要回滚基于UNDO_LOG表中数据反解析SQL达到回滚补偿的目的

• HashMap底层为什么是2倍扩容

  • 为什么扩容 因为减少hash冲突
  • (n-1)&hash(key) n-1的二进制会全为1 哈希函数2的n次幂 避免不必要的哈希冲突
  • 是否移位 不用每一个元素都进行移位

• 分布式不用外键

  • 子表父表更新数据需要检测费性能
  • 分库分表鸡肋

• mysql的解析器执行顺序

  • FROM-> JOIN->ON->WHERE->GROUP BY->HAVING->SELECT->DISTINCT->ORDER BY->LIMIT

• Myisam查询比Innodb快

  • mvvc的一个比较
  • 回表
  • 查表锁和行锁
  • innodb需要内存 myisam需要硬盘转速

• or为什么出现失效的情况

  • index_merge AND/OR 交集/并集
  • 需要回表有一个需要全扫优化器会直接全扫

• 为什么设计聚簇索引

  • 聚集连续的数据
  • 数据data访问快
  • 不需要频繁的变更非聚簇索引的数据列/抽象解耦

• ioc循环依赖解决

  • 三级缓存

		/** 1.用于存放完全初始化好的 bean，从该缓存中取出的 bean 可以直接使用 */
		private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>();
	 
		/** 2.存放 bean 工厂对象，用于解决循环依赖 */
		private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);
	 
		/** 3.存放原始的 bean 对象（尚未填充属性），用于解决循环依赖 */
		private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);

• 乐观/悲观锁的使用场景

  • 乐观锁
    • 适用于多读少写的场景
  • 悲观锁
    • 适用于多写少读的场景

• LockSupport和wait

  • unpark会直接指定要解除阻塞的线程，而notify需要知道有一个确定的线程在wait,如果有多个线程在阻塞，则不能确定知道哪个会被解除阻塞。
  • wait和notify有先后顺序，即必须先wait,再notify才能解除，而park和unpark则没有，可以先给权限，再阻塞，阻塞会直接返回。
  • wait时线程如果被interrupt，会报错InterruptedException，而park时则会正常结束。
  • wait/notify面向对象，而LockSupport面向线程

• 数据库设计三范式

  • 1．第一范式(确保每列保持原子性即列不可分(地址/省份城市))
  • 2．第二范式(确保表中的每列都和主键相关 属性都是该对象拥有的)
  • 3．第三范式(确保每列都和主键列直接相关,而不是间接相关 减少数据冗余)

• String为什么是被final修饰

• 栈帧内容

  1. 局部变量表
  2. 操作栈
  3. 动态连接
     4.方法返回地址

• GcRoot的种类

  1. 虚拟机栈
  2. 本地方法栈
     3 方法区中的静态变量和常量引用的对象
     4.程序计数器

• CopyOnWriteArrayList

  • 适用场景
    1. 需要容器承载数据
    2. 读多写少