Java基础知识总结（一）

老汉憨憨呀
239 阅读17分钟

1.java面向对象

两者的主要区别在于解决问题的方式不同：

  • 面向过程把解决问题的过程拆成一个个方法，通过一个个方法的执行解决问题。
  • 面向对象会先抽象出对象，然后用对象执行方法的方式解决问题。

另外，面向对象开发的程序一般更易维护、易复用、易扩展

2.多态的好处？举个例子

多态，顾名思义，表示一个对象具有多种的状态，具体表现为父类的引用指向子类的实例。 多态的前提：

  1. 子父类的继承关系
  2. 方法的重写
  3. 父类引用指向子类对象

动态绑定：运行期间调用的方法，是根据其具体的类型

多态的特点:

  • 对象类型和引用类型之间具有继承（类）/实现（接口）的关系；
  • 引用类型变量发出的方法调用的到底是哪个类中的方法，必须在程序运行期间才能确定；
  • 多态不能调用“只在子类存在但在父类不存在”的方法；
  • 如果子类重写了父类的方法，真正执行的是子类覆盖的方法，如果子类没有覆盖父类的方法，执行的是父类的方法。

多态的优点:

  1. 消除类型之间的耦合关系
  2. 可替换性
  3. 可扩充性
  4. 接口性
  5. 灵活性
  6. 简化性

多态的缺点: 无法直接访问子类特有的成员和成员方法。

3.JVM垃圾回收机制

GC Root
  1. 栈；
  2. 本地方法区；
  3. 方法区； 直接引用或间接引用的堆内的对象不允许删除。
GC 算法
  1. 标记-清理：缺点为容易产生内存碎片；
  2. 标记-整理：缺点为资源开销较大；
  3. 复制回收：缺点为需要2倍内存； 实际的GC，是把堆进行了划分。其中Young区，S0:S1:E=1:1:8，默认的配置，符合对象“朝生夕死”的规律。模型如下：
  • Young GC：当Eden区快要满的时候，使用复制回收算法，把未标记的对象复制到S0区，然后清理E区和S1区；当下次E区快满时，将E区 + S0区幸存对象复制到S1区。然后是交替往复的工作，即E + S1-->S0，E + S0-->S1，E + S1-->S0...
  • Full GC：如果对象被回收1次，其age加1。如果age>=15，则不放入S区，而是放入Old区。此外，Old区还存放大对象，避免多次复制导致的系统开销。如果Old区满了，则会触发Old GC，一般会伴随Young GC，称之为Full GC。此时，会stop the work，采用标记-清理或标记-整理算法进行垃圾回收。
  • 总结：Young GC主要采用复制回收算法，Full GC采用标记-清理或标记-整理算法。新生代的垃圾回收器有ParNew，老年代的垃圾回收器有CMS。

4.java如何处理异常的？有哪些异常？

java有哪些异常

image.png 图片来自：javaguide.cn/java/basis/…

image.png 图片来自：chercher.tech/java-progra…

在 Java 中，所有的异常都有一个共同的祖先 java.lang 包中的 Throwable 类。Throwable 类有两个重要的子类:

  • Exception :程序本身可以处理的异常，可以通过 catch 来进行捕获。Exception 又可以分为 Checked Exception (受检查异常，必须处理) 和 Unchecked Exception (不受检查异常，可以不处理)。
  • Error ：Error 属于程序无法处理的错误 ，我们没办法通过 catch 来进行捕获不建议通过catch捕获 。例如Java 虚拟机运行错误（Virtual MachineError）、虚拟机内存不够错误(OutOfMemoryError)、类定义错误（NoClassDefFoundError）等 。这些异常发生时，Java 虚拟机（JVM）一般会选择线程终止。

Checked Exception 即受检查异常，Java 代码在编译过程中，如果受检查异常没有被 catch/throw 处理的话，就没办法通过编译 。 除了RuntimeException及其子类以外，其他的Exception类及其子类都属于受检查异常 。常见的受检查异常有： IO 相关的异常、ClassNotFoundException 、SQLException...。

Unchecked Exception 即 不受检查异常 ，Java 代码在编译过程中 ，我们即使不处理不受检查异常也可以正常通过编译。

RuntimeException 及其子类都统称为非受检查异常，例如：NullPointerException、NumberFormatException（字符串转换为数字）、ArrayIndexOutOfBoundsException（数组越界）、ClassCastException（类型转换错误）、ArithmeticException（算术错误）等。

java如何捕捉和处理异常的

在编译生成的字节码中，每个方法都附带一个异常表。异常表中的每一个条目代表一个异常处理器，并且由from指针，to指针，target指针以及所捕获的异常类型构成。这些指针的值是字节码索引，用以定位字节码。

其中，from指针和to指针标识了该异常处理器所监控的范围，例如try代码块所覆盖的范围。target指针则指向异常处理器的起始位置，例如catch代码块的起始位置。

当程序触发异常时，Java虚拟机会从上至下遍历异常表中的所有条目。当触发异常的字节码的索引值在某个异常表条目的监控范围，Java虚拟机会判断所抛出的异常和该条目想要捕获的异常是否匹配。如果匹配，Java虚拟机会将控制流转移至该条目target指针指向的字节码。

如果遍历完所有异常表条目，Java虚拟机仍未匹配到异常处理器，那么它会弹出当前方法对应的Java栈帧，并且在调用者中重复上述操作。在最坏情况下，Java虚拟机需要遍历当前线程Java栈上所有方法的异常表。

针对异常执行路径，Java编译器会生成一个或多个异常表条目，监控整个try-catch代码块，并且捕获所有种类的异常。这些异常表条目的target指针将指向另一份复制的finally代码块。并且，在这个finally代码块的最后，Java编译器会重新抛出所捕获的异常。

可见，一共有三份finally代码块。其中，前两份分别位于try代码块和catch代码块的正常执行路径出口。最后一份则作为异常处理器，监控try代码块以及catch代码块。它将捕获try代码块触发的未被catch代码块捕获的异常，以及catch代码块触发的异常。

有个小问题？如果catch代码块捕获了异常，并且出发了另一个异常，那么finally捕获并且重抛的异常是哪个呢？答案是后者。也就是所原本的异常便会被忽略掉，不易于代码调试。

5. spring有用过吗？

6.tcp和udp的区别？三次握手和四次挥手的过程

TCPUDP备注
面向连接；面向无连接；TCP提供了检查和重传机制，序号标示，滑动窗口，确认应答。
提供可靠服务；不保证可靠；
点对点;一对一，多对一，多对多
资源消耗较高；资源消耗较少；
实时性强；

  • TCP的主要特点是：

    • 面向连接。
    • 每一条TCP连接只能是点对点的（一对一）。
    • 提供可靠交付的服务(无差错，不丢失，不重复，且按序到达)(校验和、重传控制、序号标识、滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。)。
    • 提供全双工通信。
    • 面向字节流。

  • UDP的主要特点是：

    • 无连接。
    • 尽最大努力交付(不保证可靠交付)。
    • 面向报文。
    • 无拥塞控制。
    • 支持一对一、一对多、多对一和多对多的交互通信。
    • 首部开销小（只有四个字段：源端口、目的端口、长度、检验和）。

采用TCP，一旦发生丢包，TCP会将后续的包缓存起来，等前面的包重传并接收到后再继续发送，延时会越来越大。
UDP对实时性要求较为严格的情况下，采用自定义重传机制，能够把丢包产生的延迟降到最低，尽量减少网络问题对游戏性造成影响。

TCP的三次握手：

  • 第一次握手：建立连接时，客户端发送SYN（请求同步）包到服务器，并进入SYN_SENT（请求连接）状态，等待服务器确认；
  • 第二次握手：服务器收到收到SYN包，必须确认客户端的SYN（x+1），同时自己也发送一个SYN包（SYN=y），即SYN+ACK包，此时服务器进入SYN_RECV（SYN派遣）状态；
  • 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK（y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。客户端与服务器才正式开始传输数据。
  • 理想状态下，TCP连接一旦建立，在通信双方中任何一方主动关闭连接之前，TCP连接都将被一直保持下去。

TCP的四次挥手：

  • 第一次挥手：主动关闭方调用close，会发送一个长度为0的数据包以及FIN（结束标志），用来关闭主动方到被动关闭方的数据传送（注意：此时主动关闭方还可以接受数据）；
  • 第二次挥手：被动关闭方收到FIN包，发送一个ACK给对方，确认序号为收到序号+1；
  • 第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方到数据传送；
  • 第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

7. 七层协议有哪些

8.数据库中的存储过程？

9.数据库的索引，哪些字段是个建索引？

10. drop、truncate、 delete的区别

用法不同

truncate 和不带 where 子句的 delete、以及 drop 都会删除表内的数据，但是 truncate 和 delete 只删除数据不删除表的结构(定义)，执行 drop 语句，此表的结构也会删除，也就是执行 drop 之后对应的表不复存在。

属于不同的数据库语言

truncate 和 drop 属于 DDL(数据定义语言)语句，操作立即生效，原数据不放到 rollback segment 中，不能回滚，操作不触发 trigger。而 delete 语句是 DML (数据库操作语言)语句，这个操作会放到 rollback segement 中，事务提交之后才生效。

执行速度不同

一般来说：drop > truncate > delete（这个我没有设计测试过）。

delete命令执行的时候会产生数据库的binlog日志，而日志记录是需要消耗时间的，但是也有个好处方便数据回滚恢复。

truncate命令执行的时候不会产生数据库日志，因此比delete要快。除此之外，还会把表的自增值重置和索引恢复到初始大小等。

drop命令会把表占用的空间全部释放掉。

Tips：你应该更多地关注在使用场景上，而不是执行效率。

11. 为什么会产生死锁？

什么是死锁

所谓死锁，是指多个进程在运行过程中因争夺资源而造成的一种僵局，当进程处于这种僵持状态时，若无外力作用，它们都将无法再向前推进。 因此我们举个例子来描述，如果此时有一个线程A，按照先锁a再获得锁b的的顺序获得锁，而在此同时又有另外一个线程B，按照先锁b再锁a的顺序获得锁。

产生死锁的原因

a. 竞争资源

系统中的资源可以分为两类： 可剥夺资源，是指某进程在获得这类资源后，该资源可以再被其他进程或系统剥夺，CPU和主存均属于可剥夺性资源； 另一类资源是不可剥夺资源，当系统把这类资源分配给某进程后，再不能强行收回，只能在进程用完后自行释放，如磁带机、打印机等。 产生死锁中的竞争资源之一指的是竞争不可剥夺资源（例如：系统中只有一台打印机，可供进程P1使用，假定P1已占用了打印机，若P2继续要求打印机打印将阻塞） 产生死锁中的竞争资源另外一种资源指的是竞争临时资源（临时资源包括硬件中断、信号、消息、缓冲区内的消息等），通常消息通信顺序进行不当，则会产生死锁。

b. 进程间推进顺序非法

若P1保持了资源R1,P2保持了资源R2，系统处于不安全状态，因为这两个进程再向前推进，便可能发生死锁 例如，当P1运行到P1：Request（R2）时，将因R2已被P2占用而阻塞；当P2运行到P2：Request（R1）时，也将因R1已被P1占用而阻塞，于是发生进程死锁。

死锁产生的 4 个必要条件

产生死锁的必要条件：

  • 互斥条件：进程要求对所分配的资源进行排它性控制，即在一段时间内某资源仅为一进程所占用。
  • 请求和保持条件：当进程因请求资源而阻塞时，对已获得的资源保持不放。
  • 不剥夺条件：进程已获得的资源在未使用完之前，不能剥夺，只能在使用完时由自己释放。
  • 环路等待条件：在发生死锁时，必然存在一个进程--资源的环形链。
解决死锁的基本方法
预防死锁：

资源一次性分配：一次性分配所有资源，这样就不会再有请求了：（破坏请求条件）
只要有一个资源得不到分配，也不给这个进程分配其他的资源：（破坏请保持条件）
可剥夺资源：即当某进程获得了部分资源，但得不到其它资源，则释放已占有的资源（破坏不可剥夺条件）
资源有序分配法：系统给每类资源赋予一个编号，每一个进程按编号递增的顺序请求资源，释放则相反（破坏环路等待条件）

1、以确定的顺序获得锁

如果必须获取多个锁，那么在设计的时候需要充分考虑不同线程之前获得锁的顺序。按照上面的例子，两个线程获得锁的时序图如下：

image.png 如果此时把获得锁的时序改成： image.png

那么死锁就永远不会发生。 针对两个特定的锁，开发者可以尝试按照锁对象的hashCode值大小的顺序，分别获得两个锁，这样锁总是会以特定的顺序获得锁，那么死锁也不会发生。问题变得更加复杂一些，如果此时有多个线程，都在竞争不同的锁，简单按照锁对象的hashCode进行排序（单纯按照hashCode顺序排序会出现“环路等待”），可能就无法满足要求了，这个时候开发者可以使用银行家算法，所有的锁都按照特定的顺序获取，同样可以防止死锁的发生，该算法在这里就不再赘述了，有兴趣的可以自行了解一下。

2、超时放弃

当使用synchronized关键词提供的内置锁时，只要线程没有获得锁，那么就会永远等待下去，然而Lock接口提供了boolean tryLock(long time, TimeUnit unit) throws InterruptedException方法，该方法可以按照固定时长等待锁，因此线程可以在获取锁超时以后，主动释放之前已经获得的所有的锁。通过这种方式，也可以很有效地避免死锁。 还是按照之前的例子，时序图如下：

image.png

避免死锁

  • 预防死锁的几种策略，会严重地损害系统性能。因此在避免死锁时，要施加较弱的限制，从而获得 较满意的系统性能。由于在避免死锁的策略中，允许进程动态地申请资源。因而，系统在进行资源分配之前预先计算资源分配的安全性。若此次分配不会导致系统进入不安全的状态，则将资源分配给进程；否则，进程等待。其中最具有代表性的避免死锁算法是银行家算法。

  • 银行家算法：首先需要定义状态和安全状态的概念。系统的状态是当前给进程分配的资源情况。因此，状态包含两个向量Resource（系统中每种资源的总量）和Available（未分配给进程的每种资源的总量）及两个矩阵Claim（表示进程对资源的需求）和Allocation（表示当前分配给进程的资源）。安全状态是指至少有一个资源分配序列不会导致死锁。当进程请求一组资源时，假设同意该请求，从而改变了系统的状态，然后确定其结果是否还处于安全状态。如果是，同意这个请求；如果不是，阻塞该进程知道同意该请求后系统状态仍然是安全的。

检测死锁

首先为每个进程和每个资源指定一个唯一的号码； 然后建立资源分配表和进程等待表。

解除死锁

当发现有进程死锁后，便应立即把它从死锁状态中解脱出来，常采用的方法有：

剥夺资源：从其它进程剥夺足够数量的资源给死锁进程，以解除死锁状态； 撤消进程：可以直接撤消死锁进程或撤消代价最小的进程，直至有足够的资源可用，死锁状态.消除为止；所谓代价是指优先级、运行代价、进程的重要性和价值等。

死锁检测

1、Jstack命令

jstack是java虚拟机自带的一种堆栈跟踪工具。jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息。 Jstack工具可以用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。 线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。

2、JConsole工具

Jconsole是JDK自带的监控工具，在JDK/bin目录下可以找到。它用于连接正在运行的本地或者远程的JVM，对运行在Java应用程序的资源消耗和性能进行监控，并画出大量的图表，提供强大的可视化界面。而且本身占用的服务器内存很小，甚至可以说几乎不消耗。

另参考死锁产生的原因和解锁的方法

12. 需求从提出到上线的过程，测试参与了什么

13. 讲讲testng

14. 性能测试和自动化测试？

avatar
文章
阅读
粉丝