遗留问题

问题：

1. spring bean生命周期，post service

1. 容器启动后，会对单例非懒加载的对象进行实例化
2. 安装Bean的配置信息进行属性注入
3. 如果Bean实现了BeanNameAware接口，则会调用接口的setBeanName方法，传入Bean的id
4. 如果Bean实现了BeanFactoryAware接口，则会调用接口的setBeanFactory方法，传入Bean的BeanFactory
5. 如果Bean实现了ApplicationContextAware接口，则会调用接口的setApplicationContextAware方法，获取自己的ApplicationContext
6. 如果Bean实现了BeanPostProcesser接口，则会调用接口的postProcesserBeforeInitialzation方法
7. 如果Bean实现了InitializingBean接口，则会调用afterPropertiesSet方法
8. 如果Bean配置了init-method方法，则会调用配置的方法
9. 如果Bean实现了BeanPostProcesser接口，则会调用接口的postProcesserAfterInitialztion方法
10. 可以正常使用Bean了，在IOC容器中若是单例则会进行缓存，若是多例则交给调用方管理
11. 如果Bean实现了DisposableBean接口，则会调用destory方法
12. 如果Bean配置了destory-method方法，则会执行配置的方法
    ps:
    • 上面的生命周期流程图，时候的时候注意调用先后顺序，避免属性被覆盖的现象。
    • BeanFactoryPostProcessor 主要是在Spring刚加载完配置文件，还没来得及初始化Bean的时候做一些操作。比如篡改某个Bean在配置文件中配置的内容。
    • InstantiationAwareBeanPostProcessorAdapter 基本没什么鸟用，Bean初始化后，还没有设置属性值时调用，和BeanFactoryPostProcessor一样，可以篡改配置文件加载到内存中的信息。
    • ApplicationContextAware:用处很大，注入了ApplicationContext到Bean中。
    • InitializingBean:有用处，可以在Bean属性全部改完之后，再做一些定制化操作。
    • BeanPostProcessor：没什么用，Spring框架内部使用的比较猛，像什么AOP，动态代理，都是在这搞事。后期有时间和大家分析。
    • 其他的像什么init-method，destroy方法，基本都是个摆设。。我是没怎么用过，只知道有这么回事。
      Spring核心系列之Bean的生命周期

2. spring boot starter实现

• 创建maven项目，引入spring-boot-autoconfigure和spring-boot-configuration-processor这两个依赖
• 创建配置文件的配置实体
• 创建需要被使用的类，例如服务类
• 创建自动配置类
• 在src/main/resources新建META-INF文件夹，并创建spring.factories文件（该文件并不一定需要，通过注解@ImportAutoConfiguration(XXXAutoConfiguration.class)也可以）
• 在spring.factories文件中加入org.springframework.boot.autoconfigure.EnableAutoConfiguration=xxx.xxx…XXXAutoConfiguration.class
• mvn install至本地
• 在另一项目中，引用该服务的jar包即可使用
  springboot构建自己的starter

3. @autowire和@resource区别

• @autowire：直接通过类型装配对象
• @resource：先通过名称装配对象，若名称找不到对象，再通过类型装配

4. mybatis的#和$的区别

• #{}：是预编译处理，将其替换成?，通过preparedStatement的set方法来赋值，能够防止SQL注入，原因是会将用户数据和sql语句分开
• ${}：是字符串替换，直接替换成变量的值

5. hashmap什么情况出现线程不安全

Java容器（Java复习一）

6. cpu高了之后怎么排查

1. 通过ps aux | grep java查看占用较多CPU的进程ID tid
2. 将tid转为16进制
3. 通过jstack命令定位具体的线程和代码
4. 如果是GC线程占用，则通过jstat查看内存状况，生成dump文件，通过jvisualvm.exe进行分析
   记一次java程序CPU占用过高问题排查
   线上java程序CPU占用过高问题排查

7. 遇到过什么线上问题解决，jvm调优

8. 出现OOM的场景

• java.lang.OutOfMemoryError: Java heap space：堆内存空间不足
  • 通过jmap查看dump内存
  • 查看GC日志
  • 发现新生代晋升到老年代时，老年代没有足够空间
  • 先调大堆空间，若还出现OOM则是内存溢出
  • -XX:+HeapDumpOnOutOfMemeryError通过出现OOM时打出dump日志的参数设置，查看内存溢出的对象，并进行排查
    一次应用OOM排查
• java.lang.OutOfMemoryError: PermGen space：存放类和常量池的空间不足，如大量JSP导致，动态编译成java Servle类
• java.lang.OutOfMemoryError: unable to create new native thread：无法创建新的线程，1.剩余内存无法创建新线程，一个新线程占用1M内存空间；2.linux设置的最大进程数为1024，java虚拟机的线程加上服务器的用户线程已经达到该值，导致
  • 以上展开：
  • 通过free 查看剩余可用内存，还有700M，排除问题1
  • 通过ulimit -a查看linux的最大进程
  • 通过jstack统计线程数
  • 通过pstack查看Linux的线程数
  • 通过jstack查看线程阻塞位置为日志打印
  • 发现IO在整点时由于日志切割被阻塞，导致线程阻塞
  • 复现问题：tomcat线程设置1500，人工IO加压，IO不低于50%，操作系统用户进程设置为1024
  • 优化：日志将定时切割改为滚动，升级Log4j日志，减少tomcat线程数
• java.lang.OutOfMemoryError：GC overhead limit exceeded：垃圾回收时，使用的时间过长，回收的内存却很小
  jvm系列(十):教你如何成为Java的OOM Killer

9. spring mvc请求流程

Spring MVC（Spring复习二）

10. spring5.0新特性

Spring（Spring复习一）

11. jdk1.8新特性

• lambda：把函数或者执行语句块作为参数或者变量，实际上是java中定义的函数式接口和方法引用或者构造器引用
• stream：把真正的函数式编程风格引入到Java中，简化了集合和数组的操作
• 接口：支持默认方法和静态方法，其中默认方法可被重写
• 日期类：操作更加便利，保证了线程安全；如何在JDK1.8中愉快地处理日期和时间
• Optional类：解决空指针异常，提供默认值等
• 注解：注解的支持得到了扩展，支持局部变量，泛型类，父类与接口，支持重复注解

12. pg相对于mysql的优势

• pg：更加稳定，效率更高，“无锁定读取”，读取快照的方式保证性能，对json和同步数据的支持更好

• mysql：对内存利用更好，出错后，问题排查更加方便

• 目前：相差并没有那么大，新的版本都补足了自己的问题

  PostgreSQL 与 MySQL 相比，优势何在？
  “王者对战”之 MySQL 8 vs PostgreSQL 10

13. json和xml解析

• Gson：实体转换不会出现问题，无依赖，性能相对低一些

• Fastjson：复杂实体转换会出现问题，无其他依赖，性能相对较好

• jackson：复杂实体转换会出现问题，依赖较少，性能相对较好，社区比较活跃

• DOM：将xml数据加载到内存，构建节点整颗树操作；优点：操作方便；确定：需要加载所有的xml数据到内存，资源消耗大

• SAX：分析能够立即开始，无需加载所有数据，效率较高，但是程序处理复杂，不支持XPath

• DOM4J：性能较好，支持XPath，开发较为方便

  几种常用JSON库性能比较
  四种生成和解析XML文档的方法详解（介绍+优缺点比较+示例）

14. activemq和其他mq比较

activemq 复习一

15. https如何实现安全

https原理详解

16. 高并发的场景如何实现

17. zookeeper使用场景

ZooKeeper学习第一期—Zookeeper简单介绍
ZooKeeper学习笔记之扫盲
Zookeeper教程

18. 分库分表的划分字段,sql优化order by limit

19. 容器源码，扩容机制，hash碰撞机制

HashMap源码读后感

20. dubbo原理

21. jvm调优，主要参数，java内存模型，大数据量，高吞吐量，oom

Jvm 系列(六):Java 服务 GC 参数调优案例
java内存模型
JVM性能调优入门
JVM调优总结(这个总结得比较全面)+
又一次线上OOM排查经过

22. 设计模式

大话设计模式笔记

23. mybatis三层架构

24. tomcat调优

（荐）Tomcat 调优及 JVM 参数优化
Tomcat和JVM的性能调优总结

25. 分布式集群项目只执行单一任务

26. 分布式数据一致性

CAP 定理的含义
分布式系统数据一致性的解决方案
浅析数据一致性

27. 分布式activemq如何保持数据一致性，以及有序性

28. 分库分表查询问题

29. Redis SetNX 方法的底层原理

30. Redis 性能差或影响性能的命令

31. 秘钥加密后的数据是否每次都一样

1. 工作模式ECB以外的加密模式，会根据每次随机的IV向量来是加密结果不同。
2. 或者通过填充不同的随机数来使加密结果不同。

32. 复合索引注意事项

mysql 复习一

33. 分布式系统相对单体的优缺点

dubbo详解

34. pg与mysql对比

mysql 复习一

35. maven的scope取值，以及provide的作用和使用场景

• compile：默认值，编译，测试，运行和打包阶段都会使用依赖的jar包
• test：只有在测试的编译和运行时才会用到该依赖，在主代码的编译和运行时不会依赖，例如juint
• provided：在编译和测试时会用到该依赖，运行和打包时会将该依赖排除在外，例如selvert-api
• runtime：只有在运行时使用该依赖，编译时不需要使用，例如JDBC的实现包
• system：系统依赖范围。依赖范围和compile一致，但依赖的jar为本地操作系统的jar，需要通过systemPath配置依赖文件的路径

36. maven版本依赖冲突解决

1. 通过父pom的依赖管理统一管理
2. 通过Idea的maven helper插件定位冲突的包，进行排包
3. 通过mvn dependency:tree 定位冲突的包，进行排包

Maven中 jar包冲突原理与解决办法

37. git提交被覆盖，如何找回，以及其他问题

1.日志打印
2.文件上传原理
3.mybatis运行原理，包含拦截器
4.spring生命周期
4.1.factoryBean和beanFactory区别
5.dubbo发布订阅原理
6.dubbo和zk断开后，能够存活多久
7.容器源码
8.linux排查java问题命令
9.单点登入
10.nginx