笔记：Java后端--八股文/面试题1

1.什么是克隆、浅拷贝、深拷贝、零拷贝？

浅拷贝（shallow copy）：只复制指向某个对象的指针，而不复制对象本身，新旧对象共享一块内存；
深拷贝（deep copy）：复制并创建一个一摸一样的对象，不共享内存，修改新对象，旧对象保持不变；

（1）什么要使用克隆？
想对一个对象进行复制，又想保留原有的对象进行接下来的操作，这个时候就需要克隆了。
（2）如何实现对象克隆？
实现Cloneable接口，重写clone方法；
实现Serializable接口，通过对象的序列化和反序列化实现克隆，可以实现真正的深克隆。
BeanUtils，apache和Spring都提供了bean工具，只是这都是浅克隆。
浅克隆：仅仅克隆基本类型变量，不克隆引用类型变量；
深克隆：既克隆基本类型变量，又克隆引用类型变量；

零拷贝（Zero-Copy）是一种 I/O 操作优化技术，可以快速高效地将数据从文件系统移动到网络接口，而不需要将其从内核空间复制到用户空间。其在 FTP 或者 HTTP 等协议中可以显著地提升性能。但是需要注意的是，并不是所有的操作系统都支持这一特性，目前只有在使用 NIO 和 Epoll 传输时才可使用该特性。
需要注意，它不能用于实现了数据加密或者压缩的文件系统上，只有传输文件的原始内容。这类原始内容也包括加密了的文件内容。

2.在jdk1.5中引入了泛型，泛型的存在是用来解决什么问题

Java泛型这个特性是从JDK 1.5才开始加入的，因此为了兼容之前的版本，Java泛型的实现采取了“伪泛型”的策略，即Java在语法上支持泛型，但是在编译阶段会进行所谓的“类型擦除”（Type Erasure），将所有的泛型表示（尖括号中的内容）都替换为具体的类型（其对应的原生态类型），就像完全没有泛型一样。
泛型的本质是为了参数化类型（在不创建新的类型的情况下，通过泛型指定的不同类型来控制形参具体限制的类型）。也就是说在泛型使用过程中，操作的数据类型被指定为一个参数，这种参数类型可以用在类、接口和方法中，分别被称为泛型类、泛型接口、泛型方法。
● 适用于多种数据类型执行相同的代码（代码复用）
● 泛型中的类型在使用时指定，不需要强制类型转换（类型安全，编译器会检查类型）

泛型上下限
为了解决泛型中隐含的转换问题，Java泛型加入了类型参数的上下边界机制。<? extends A>表示该类型参数可以是A(上边界)或者A的子类类型。编译时擦除到类型A，即用A类型代替类型参数。这种方法可以解决开始遇到的问题，编译器知道类型参数的范围，如果传入的实例类型B是在这个范围内的话允许转换，这时只要一次类型转换就可以了，运行时会把对象当做A的实例看待。
如何理解Java中的泛型是伪泛型？泛型中类型擦除
Java泛型这个特性是从JDK 1.5才开始加入的，因此为了兼容之前的版本，Java泛型的实现采取了“伪泛型”的策略，即Java在语法上支持泛型，但是在编译阶段会进行所谓的“类型擦除”（Type Erasure），将所有的泛型表示（尖括号中的内容）都替换为具体的类型（其对应的原生态类型），就像完全没有泛型一样。理解类型擦除对于用好泛型是很有帮助的，尤其是一些看起来“疑难杂症”的问题，弄明白了类型擦除也就迎刃而解了。

泛型的类型擦除原则是：
● 消除类型参数声明，即删除<>及其包围的部分。
● 根据类型参数的上下界推断并替换所有的类型参数为原生态类型：如果类型参数是无限制通配符或没有上下界限定则替换为Object，如果存在上下界限定则根据子类替换原则取类型参数的最左边限定类型（即父类）。
● 为了保证类型安全，必要时插入强制类型转换代码。
● 自动产生“桥接方法”以保证擦除类型后的代码仍然具有泛型的“多态性”。

那么如何进行擦除的呢？
● 擦除类定义中的类型参数 - 无限制类型擦除
当类定义中的类型参数没有任何限制时，在类型擦除中直接被替换为Object，即形如和<?>的类型参数都被替换为Object。

● 擦除类定义中的类型参数 - 有限制类型擦除
当类定义中的类型参数存在限制（上下界）时，在类型擦除中替换为类型参数的上界或者下界，比如形如和<? extends Number>的类型参数被替换为Number，<? super Number>被替换为Object。

● 擦除方法定义中的类型参数
擦除方法定义中的类型参数原则和擦除类定义中的类型参数是一样的，

3.==、equals、hashcode的问题

对于基本类型，==比较的是值
对于引用类型，==比较的是地址；

equals不能用于基本类型的比较；
如果没有重写equals，equals就相当于==；
如果重写了equals方法，equals比较的是对象的内容；

hashcode可以看做的一个对象的内存地址

hashCode() 的作用是获取哈希码，也称为散列码；它实际上是返回一个int整数。这个哈希码的作用是
确定该对象在哈希表中的索引位置。hashCode() 定义在JDK的Object.java中，Java中的任何类都包含有hashCode() 函数。
散列表存储的是键值对(key-value)，它的特点是：能根据“键”快速的检索出对应的“值”。这其中就利用到了散列码！（可以快速找到所需要的对象）

为什么要有hashCode：
以“HashSet如何检查重复”为例子来说明为什么要有hashCode：
对象加入HashSet时，HashSet会先计算对象的hashcode值来判断对象加入的位置，看该位置是否有值，如果没有、HashSet会假设对象没有重复出现。但是如果发现有值，这时会调用equals（）方法来检查两个对象是否真的相同。如果两者相同，HashSet就不会让其加入操作成功。如果不同的话，就会重新散列到其他位置。这样就大大减少了equals的次数，相应就大大提高了执行速度。
如果两个对象相等，则hashcode一定也是相同的两个对象相等,对两个对象分别调用equals方法都返回true两个对象有相同的hashcode值，它们也不一定是相等的因此，equals方法被覆盖过，则hashCode方法也必须被覆盖hashCode()的默认行为是对堆上的对象产生独特值。如果没有重写hashCode()，则该class的两个对象无论如何都不会相等（即使这两个对象指向相同的数据）

有没有可能2个不相等的对象有相同的hashcode?
● 如果两个对象equals，Java运行时环境会认为他们的hashcode一定相等
● 如果两个对象不equals，他们的hashcode有可能相等
● 如果两个对象hashcode相等，他们不一定equals
● 如果两个对象hashcode不相等，他们一定不equals

4.用过哪些Map类，都有什么区别，HashMap是线程安全的吗,并发下使用的Map是什么，他们内部原理分别是什么，比如存储方式，hashcode，扩容，默认容量等。

有HashMap、HashTable、LinkedHashMap、TreeMap
在Map中插入，删除，定位元素：HashMap
要按照自定义顺序或自然顺序遍历：TreeMap
要求输入顺序和输出顺序相同：LinkedHashMap
从内部数据结构分析：
● HashMap 数组+链表/红黑树 （链表长度超过8转成红黑树）
● HashTable 数组+链表
● LinkedHashMap 双向链表
● TreeMap 红黑树
从线程安全分析：
● HashMap 非线程安全
● HashTable 线程安全的
● LinkedHashMap 非线程安全
● TreeMap 非线程安全的

5.String、Stringbuffer、stringbuilder的问题

性能：StringBuilder > StringBuffer > String
但是stringbuilder不是线程安全的，
String对象是不可变的，改变string变量的值时，会让该变量指向新的内存空间，而其余二者不会。

String是final修饰的，不可变，每次操作都会产生新的String对象
StringBuffer和StringBuilder都是在原对象上操作
StringBuffer是线程安全的，StringBuilder线程不安全的
StringBuffer方法都是synchronized修饰的

场景：经常需要改变字符串内容时使用后面两个
优先使用StringBuilder，多线程使用共享变量时使用StringBuffer

6.jdk、jre、jvm

JDK：
Java Develpment Kit java 开发工具
JRE：
Java Runtime Environment java运行时环境
JVM：
java Virtual Machine java 虚拟机

JDK里面有JVM(bin)、JRE和类库(lib)
JRE里面有JVM(bin)和类库(lib)

7.如何判断一个对象是否可以回收？

引用计数法
主要思想是：给对象添加一个引用计数器，这个对象被引用一次，计数器就加1；不再引用了，计数器就减1。如果一个对象的引用计数器为0，说明没有人使用这个对象，那么这个对象就可以被回收了。这种方法实现起来比较简单，效率也比较高，大多数情况下都是有效的。但是，这种方法有一个漏洞。比如A.property = B，B.property = A，A和B两个对象互相引用，并且没有其他对象引用A和B。按照引用计数法的思想，A和B对象的引用计数器都不为0，都不能被释放，但实际情况是A和B已经没人使用他们了，这就造成了内存泄漏。所以，引用计数法虽然实现简单，但并不是一个完美的解决方案，实际中的Java也没有采用它。

可达性分析算法
首先确定确定一系列肯定不能被回收的对象，即GC Roots。然后，从这些GC Roots出发，向下搜索，去寻找它直接和间接引用的对象。最后，如果一个对象没有被GC Roots直接或间接地引用，那么这个对象就可以被回收了。这种方法可以有效解决循环引用的问题，实际中Java也是采用这种判断方法。那么问题来了，哪些对象可以作为GC Roots呢？
第一类，系统类对象（System Class）。比如，java.lang.String的Class对象，这个也很好理解，如果这些核心的系统类对象被回收了，程序就没办法运行了。
第二类，native方法引用的对象。
第三类，活动线程中正在引用的对象。可以看出，代码中变量o指向的Object对象可以被当作GC Roots。
第四类，正在加锁的对象。

在可达性分析算法中，判断一个对象是不是可以被回收，主要看从GC Roots出发是否可以找到一个引用指向该对象。java中的引用一共有四种，按照引用的强弱依次为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）。这样就可以对不同引用指向的对象采取不同的回收策略。比如一个强引用指向一个对象，那么这个对象肯定不会被回收，哪怕发生OOM。而对于弱引用指向的对象，只要发生垃圾回收，该对象就会被回收。下面详细介绍下不同引用的用法。
强引用 所谓强引用，就是平时使用最多的，类似于Object obj = new Object()的引用。垃圾回收器永远不会回收被强引用指向的对象。
软引用 在Java中使用SoftReference类来实现软引用。在下面的代码中，softReference作为软用指向一个Object对象，而otherObject变量可以通过软引用的get方法间接引用到Object对象。
弱引用，相比于软引用，它的引用程度更弱。只要发生垃圾回收，弱引用指向的对象都会被回收。话不多说，直接上代码。跟软引用的demo差不多，唯一不同的是每个byte的数组的大小变成了2K，这样堆肯定放的下，也不会发生垃圾回收。
虚引用 与软引用和虚引用不同，虚引用必须配合引用队列使用，而且不能通过虚引用获取到虚引用指向的对象。在Java中虚引用使用PhantomReference类来表示，从PhantomReference的源码可以看出调用虚引用的get方法始终返回的是null，而且PhantomReference只提供了包含引用队列的有参构造器，这也就是说虚引用必须结合引用队列使用。

总结
● JVM采用可达性分析算法来判断堆中有哪些对象可以被回收。
● 主要有四类对象可作为GC Roots：系统类对象、Native方法引用的对象、活动线程引用的对象以及正在加锁的对象。
● Java中常用的引用主要有四种，强引用、软引用、弱引用和虚引用，对不同引用指向的对象，JVM有不同的回收策略。
● 对于强引用指向的对象，垃圾回收器不会将其回收，即使是发生OOM。
● 对于软引用指向的对象，当内存不够时，垃圾回收器会将其回收。这个特点可以用来实现缓存，当内存不足时JVM会自动清理掉这些缓存。
● 对于弱引用指向的对象，当发生垃圾回收时，垃圾回收器会将其回收。
● 对于虚引用，必须配合引用队列使用，而且不能通过虚引用获取到虚引用指向的对象，为一个对象关联虚引用的唯一目的就是在该对象被垃圾回收时收到一个系统通知。

8.JAVA的反射机制

什么是反射？
反射就是在运行时才知道要操作的类是什么，并且可以在运行时获取类的完整构造，并调用对应的方法。

反射的主要功能
● 在运行时判断任意一个对象所属的类
● 在运行时构造任意一个类的对象
● 在运行时判断任意一个类所具有的成员变量和方法
● 在运行时调用任意一个对象的方法，通过反射甚至可以调用到private修饰的方法
● 生成动态代理

反射的应用
● Spring 框架的 IOC 基于反射创建对象和设置依赖属性。
● Spring MVC 的请求调用对应方法，也是通过反射。
● JDBC 的 Class.forName(String className) 方法，也是使用反射。

反射的优点

1. 增加程序的灵活性，避免将程序写死到代码里。
2. 可以在程序运行的过程中，操作这些对象。
3. 测试时可以利用反射 API 访问类的私有成员，以保证测试代码覆盖率。

反射的缺点

1. 性能问题
   a. 使用反射基本上是一种解释操作，用于字段和方法接入时要远慢于直接代码。因此Java反射机制主要应用在对灵活性和扩展性要求很高的系统框架上,普通程序不建议使用。
   b. 反射包括了一些动态类型，所以JVM无法对这些代码进行优化。因此，反射操作的效率要比那些非反射操作低得多。我们应该避免在经常被 执行的代码或对性能要求很高的程序中使用反射。
2. 使用反射会模糊程序内部逻辑
   a. 程序人员希望在源代码中看到程序的逻辑，反射等绕过了源代码的技术，因而会带来维护问题。反射代码比相应的直接代码更复杂。
3. 内部暴露
   a. 由于反射允许代码执行一些在正常情况下不被允许的操作（比如访问私有的属性和方法），所以使用反射可能会导致意料之外的副作用－－代码有功能上的错误，降低可移植性。反射代码破坏了抽象性，因此当平台发生改变的时候，代码的行为就有可能也随着变化。

软件工程没有银弹。很多程序架构，尤其是三方框架，无法保证自己的封装是完美的。如果没有反射，对于外部类的私有成员，我们将一筹莫展，所以我们有了反射这一后门，为程序设计提供了更大的灵活性。工具本身并没有错，关键在于如何正确地使用。

介绍
机制是指在程序的运行状态中，可以构造任意一个类的对象，可以了解任意一个对象所属的类，可以了解任意一个类的成员变量和方法，可以调用任意一个对象的属性和方法。这种动态获取程序信息以及动态调用对象的功能称为Java语言的反射机制。反射被视为动态语言的关键，反射让Java成为一个准动态语言 。缺点增加不安全性。
● 反射让开发人员可以通过外部类的全路径名创建对象，并使用这些类，实现一些扩展的功能。
● 反射让开发人员可以枚举出类的全部成员，包括构造函数、属性、方法。以帮助开发者写出正确的代码。
● 测试时可以利用反射 API 访问类的私有成员，以保证测试代码覆盖率。

反射API类
● Field 类：提供有关类的属性信息，以及对它的动态访问权限。它是一个封装反射类的属性的类。
● Constructor 类：提供有关类的构造方法的信息，以及对它的动态访问权限。它是一个封装反射类的构造方法的类。
● Method 类：提供关于类的方法的信息，包括抽象方法。它是用来封装反射类方法的一个类。
● Class 类：表示正在运行的 Java 应用程序中的类的实例。
● Object 类：Object 是所有 Java 类的父类。所有对象都默认实现了 Object 类的方法。

9.Spring bean加载流程和生命周期

Spring的bean生命周期其实最核心的分为4个步骤，只要理清三个关键的步骤，其他的只是在这三个细节中添加不同的细节实现,也就是spring的bean生明周期：

实例化和初始化的区别：实例化是在jvm的堆中创建了这个对象实例，此时它只是一个空的对象，所有的属性为null。而初始化的过程就是讲对象依赖的一些属性进行赋值之后，调用某些方法来开启一些默认加载。比如spring中配置的数据库属性Bean，在初始化的时候就会将这些属性填充，比如driver、jdbcurl等,然后初始化连接

实例化 Instantiation
AbstractAutowireCapableBeanFactory.doCreateBean中会调用createBeanInstance()方法,该阶段主要是从beanDefinitionMap循环读取bean,获取它的属性，然后利用反射(core包下有ReflectionUtil会先强行将构造方法setAccessible(true)读取对象的构造方法(spring会自动判断是否是有参数还是无参数，以及构造方法中的参数是否可用),然后再去创建实例（newInstance）

初始化
初始化主要包括两个步骤,一个是属性填充，另一个就是具体的初始化过程
属性赋值 PopulateBean()会对bean的依赖属性进行填充，@AutoWired注解注入的属性就发生这个阶段，假如我们的bean有很多依赖的对象，那么spring会依次调用这些依赖的对象进行实例化，注意这里可能会有循环依赖的问题。

初始化 Initialization
初始化的过程包括将初始化好的bean放入到spring的缓存中、填充我们预设的属性进一步做后置处理等

使用和销毁 Destruction
在Spring将所有的bean都初始化好之后，我们的业务系统就可以调用了。而销毁主要的操作是销毁bean，主要是伴随着spring容器的关闭，此时会将spring的bean移除容器之中。此后spring的生命周期到这一步彻底结束，不再接受spring的管理和约束。

总结：
第一步 通过构造器创建bean
第二步 为bean的属性设置值和其他bean引用
第三步 把bean实例传递bean后置处理器
第四步 调用bean的初始化的方法
第五步 把bean实例传递bean后置处理器
第六步 bean可以使用了
第七步 当容器关闭时候，调用bean的销毁方法

Javabean的生命周期：
1、解析类得到BeanDefinition
2、如果有多个构造方法，则要推断构造方法
3、确定好构造方法后，进行实例化得到一个对象
4、对对象中的加了@Autowired注解的属性进行属性填充
5、回调Aware方法，比如BeanNameAware，BeanFactoryAware
6、调用BeanPostProcessor的初始化前的方法
7、调用初始化方法
8、调用BeanPostProcessor的初始化后的方法，在这里会进行AOP
9、如果当前创建的bean是单例的则会把bean放入单例池
10、使用bean
11、Spring容器关闭时调用DisposableBean中destory()方法

10.Spring框架中的单例bean是线程安全的吗?

在Spring容器中，除了很多Spring内置的Bean以外，其他的Bean都是我们自己通过Spring配置来声明的，然后，由Spring容器统一加载。我们在Spring声明配置中通常会配置以下内容，如：class（全类名）、id（也就是Bean的唯一标识）、 scope（作用域）以及lazy-init（是否延时加载）等。之后，Spring容器根据配置内容使用对应的策略来创建Bean的实例。因此，Spring容器中的Bean其实都是根据我们自己写的类来创建的实例。因此，Spring中的Bean是否线程安全，跟Spring容器无关，只是交由Spring容器托管而已。

Spring Bean的作用域。
在Spring定义的作用域中，其中有 prototype（ 多例Bean ）和 singleton （ 单例Bean）。那么，定义为 prototype 的Bean，是在每次 getBean 的时候都会创建一个新的对象。定义为 singleton 的Bean，在Spring容器中只会存在一个全局共享的实例。

在Spring容器中，什么样的Bean会存在线程安全问题。
多例Bean每次都会新创建新实例，也就是说线程之间不存在Bean共享的问题。因此，多例Bean是不存在线程安全问题的。而单例Bean是所有线程共享一个实例，因此，就可能会存在线程安全问题。

但是单例Bean又分为无状态Bean和有状态Bean。在多线程操作中只会对Bean的成员变量进行查询操作，不会修改成员变量的值，这样的Bean称之为无状态Bean。所以，可想而知，无状态的单例Bean是不存在线程安全问题的。但是，在多线程操作中如果需要对Bean中的成员变量进行数据更新操作，这样的Bean称之为有状态Bean，所以，有状态的单例Bean就可能存在线程安全问题。

所以，最终我们得出结论，在Spring中，只有有状态的单例Bean才会存在线程安全问题。我们在使用Spring的过程中，经常会使用到有状态的单例Bean。

如果真正遇到了线程安全问题，我们又该如何处理呢？
1、将Bean的作用域由 “singleton” 单例 改为 “prototype” 多例。
2、在Bean对象中避免定义可变的成员变量，当然，这样做不太现实，就当我没说。
3、在类中定义 ThreadLocal 的成员变量，并将需要的可变成员变量保存在 ThreadLocal 中，ThreadLocal 本身就具备线程隔离的特性，这就相当于为每个线程提供了一个独立的变量副本，每个线程只需要操作自己的线程副本变量，从而解决线程安全问题。