什么是线程死锁?死锁如何产生?如何避免线程死锁?
死锁的介绍:
线程死锁是指由于两个或者多个线程互相持有对方所需要的资源,导致这些线程处于等待状态,无法前往执行。当线程进入对象的synchronized代码块时,便占有了资源,直到它退出该代码块或者调用wait方法,才释放资源,在此期间,其他线程将不能进入该代码块。当线程互相持有对方所需要的资源时,会互相等待对方释放资源,如果线程都不主动释放所占有的资源,将产生死锁。
死锁的产生的一些特定条件:
1、互斥条件:进程对于所分配到的资源具有排它性,即一个资源只能被一个进程占用,直到被该进程释放 。
2、请求和保持条件:一个进程因请求被占用资源而发生阻塞时,对已获得的资源保持不放。
3、不剥夺条件:任何一个资源在没被该进程释放之前,任何其他进程都无法对他剥夺占用。
4、循环等待条件:当发生死锁时,所等待的进程必定会形成一个环路(类似于死循环),造成永久阻塞。
如何避免:
1、加锁顺序:
当多个线程需要相同的一些锁,但是按照不同的顺序加锁,死锁就很容易发生。如果能确保所有的线程都是按照相同的顺序获得锁,那么死锁就不会发生。当然这种方式需要你事先知道所有可能会用到的锁,然而总有些时候是无法预知的。
2、加锁时限:
加上一个超时时间,若一个线程没有在给定的时限内成功获得所有需要的锁,则会进行回退并释放所有已经获得的锁,然后等待一段随机的时间再重试。但是如果有非常多的线程同一时间去竞争同一批资源,就算有超时和回退机制,还是可能会导致这些线程重复地尝试但却始终得不到锁。
3、死锁检测:
死锁检测即每当一个线程获得了锁,会在线程和锁相关的数据结构中(map、graph等等)将其记下。除此之外,每当有线程请求锁,也需要记录在这个数据结构中。死锁检测是一个更好的死锁预防机制,它主要是针对那些不可能实现按序加锁并且锁超时也不可行的场景。
大家觉得本次面试题总结的写得不错的朋友,大家可以转发+关注,然后扫描下方二维码获取更多面试题以及答案— 扫描添加暗号:【CSDN】
notify和notifyAll区别
他们的作用都是通知处于等待该对象的线程。
1、notifyAll使所有原来在该对象上等待被notify的线程统统退出wait的状态,变成等待该对象上的锁,一旦该对象被解锁,他们就会去竞争。
2、notify是通知其中一个线程,不会通知所有的线程。
谈一谈对MySQL InnoDB的认识
介绍:
InnoDB引擎是MySQL数据库的一个重要的存储引擎,和其他存储引擎相比,InnoDB引擎的优点是支持兼容ACID的事务(类似于PostgreSQL),以及参数完整性(有外键)等。现在Innobase实行双认证授权.MySQL5.5.5以后默认的存储引擎都是InnoDB引擎。
特点是:
1、具有较好的事务支持:支持4个事务隔离级别,支持多版本读
2、行级锁定:通过索引实现,全表扫描仍然会是表锁,注意间隙锁的影响
3、读写阻塞与事务隔离级别相关
4、具有非常高效的缓存特性:能缓存索引,也能缓存数据
5、整个表和主键以Cluster方式存储,组成一颗平衡树
6、所有Secondary Index都会保存主键信息
适用场景:
1、需要事务支持(具有较好的事务特性)
2、行级锁定对高并发有很好的适应能力,但需要确保查询是通过索引完成
3、数据更新较为频繁的场景
4、数据一致性要求较高
5、硬件设备内存较大,可以利用InnoDB较好的缓存能力来提高内存利用率,尽可能减少磁盘IO
谈一谈数据库事务的隔离级别?
1、Read uncommitted(读未提交)就是一个事务可以读取另一个未提交事务的数据。
2、Read committed(读提交)就是一个事务要等另一个事务提交后才能读取数据。
3、Repeatable read(重复读)就是在开始读取数据(事务开启)时,不再允许修改操作。
4、Serializable(序列化)在该级别下,事务串行化顺序执行,可以避免脏读、不可重复读与幻读。是最高的事务隔离级别,但是这种事务隔离级别效率低下,比较耗数据库性能,一般不使用。
事务的作用就是保证数据的一致性、完整性。事务隔离级别越高,在并发下会产生的问题就越少,但同时付出的性能消耗也将越大,因此很多时候必须在并发性和性能之间做一个权衡。所以设立了几种事务隔离级别,以便让不同的项目可以根据自己项目的并发情况选择合适的事务隔离级别,对于在事务隔离级别之外会产生的并发问题,在代码中做补偿。
相关阅读:
MySQL主备同步的基本原理
MySQL支持单向、异步复制,复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。
MySQL复制是基于主服务器在二进制日志中跟踪所有对数据库的更改。因此,要进行复制,必须在主服务器上启用二进制日志。每个从服务器从主服务器接收主服务器已经记录到日志的数据。
当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新,并在本机上执行相同的更新。然后封锁并等待主服务器通知新的更新。从服务器执行备份不会干扰主服务器,在备份过程中主服务器可以继续处理更新。
最后,趁着周末晾一晾小编的Java交流QQ群,虽然吹水较多,但是偶尔时不时的群里也能讨论个不错的题,有兴趣的可以加入:696209224
相关阅读:
Java语言中一个显著的特点就是引入了垃圾回收机制,这个大家都清楚,垃圾回收的概念这里也不做介绍,重点是垃圾回收是在什么时候开始?对什么东西,做了什么事情?
GC何时开始:
所有的回收器类型都是基于分代技术来实现的,那就必须要清楚对象按其生命周期是如何划分的。
- 年轻代:划分为三个区域:原始区(Eden)和两个小的存活区(Survivor),两个存活区按功能分为From和To。绝大多数的对象都在原始区分配,超过一个垃圾回收操作仍然存活的对象放到存活区。垃圾回收绝大部分发生在年轻代。
- 年老代:存储年轻代中经过多个回收周期仍然存活的对象,对于一些大的内存分配,也可能直接分配到永久代。
- 持久代:存储类、方法以及它们的描述信息,这里基本不产生垃圾回收。
有了以上这些铺垫之后开始回答GC何时开始:
Eden内存满了之后,开始Minor GC(从年轻代空间回收内存被称为 Minor GC);升到老年代的对象所需空间大于老年代剩余空间时开始Full GC(但也可能小于剩余空间时,被HandlePromotionFailure参数强制Full GC)
对什么东西操作,即垃圾回收的对象是什么:
从root开始搜索没有可达对象,而且经过第一次标记、清理后,仍然没有复活的对象。
做了什么东西:
主要做了清理对象,整理内存的工作。具体的引申如下
垃圾回收器的类型:
- 串行垃圾回收器(Serial Garbage Collector)
- 并行垃圾回收器(Parallel Garbage Collector)
- 并发标记扫描垃圾回收器(CMS Garbage Collector)
- G1垃圾回收器(G1 Garbage Collector)
垃圾回收算法:
- 引用计数法
- 标记清除法
- 复制算法
- 标记压缩算法
- 分代算法
- 分区算法
以上这些,可以自己了解一下,这里列举几篇相关文章:
类在虚拟机中的加载过程
加载Loading:
通过一个类的全限定名来获取一个二进制字节流、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构、在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口。
验证Verification:
确保Class文件的字节流中包含的信息符合当前虚拟机的要求,并不会危害虚拟机的自身安全。
准备Preparation:
正式为类变量分配内存并设置类变量初始值。
解析Resolution:
虚拟机将常量池内的符号引用替换为直接引用的过程。
初始化Initialization:
类加载过程的最后一步,到了这个阶段才真正开始执行类中定义的Java程序代码。
使用Using:
根据你写的程序代码定义的行为执行。
卸载Unloading:
GC负责卸载,这部分一般不用讨论。
以上这些抛砖引玉,欢迎留言更清晰的类加载过程,相关文章可以阅读:
强引用、软引用、弱引用、虚引用与GC的关系
强引用:new出的对象之类的引用,只要强引用还在,永远不会回收。
软引用:引用但非必须的对象,内存溢出异常之前回收。
弱引用:非必须的对象,对象只能生存到下一次垃圾收集发生之前。
虚引用:对生存时间无影响,在垃圾回收时得到通知。
这个相对好理解了,相关阅读如下:
说一下spring中Bean的作用域
singleton:
Spring IoC容器中只会存在一个共享的Bean实例,无论有多少个Bean引用它,始终指向同一对象。Singleton作用域是Spring中的缺省作用域。
prototype:
每次通过Spring容器获取prototype定义的bean时,容器都将创建一个新的Bean实例,每个Bean实例都有自己的属性和状态,而singleton全局只有一个对象。
request:
在一次Http请求中,容器会返回该Bean的同一实例。而对不同的Http请求则会产生新的Bean,而且该bean仅在当前Http Request内有效。
session:
在一次Http Session中,容器会返回该Bean的同一实例。而对不同的Session请求则会创建新的实例,该bean实例仅在当前Session内有效。
global Session:
在一个全局的Http Session中,容器会返回该Bean的同一个实例,仅在使用portlet context时有效。
说一下spring中Bean的生命周期
- 实例化一个Bean,也就是我们通常说的new。
- 按照Spring上下文对实例化的Bean进行配置,也就是IOC注入。
- 如果这个Bean实现了BeanNameAware接口,会调用它实现的setBeanName(String beanId)方法,此处传递的是Spring配置文件中Bean的ID。
- 如果这个Bean实现了BeanFactoryAware接口,会调用它实现的setBeanFactory(),传递的是Spring工厂本身(可以用这个方法获取到其他Bean)。
- 如果这个Bean实现了ApplicationContextAware接口,会调用setApplicationContext(ApplicationContext)方法,传入Spring上下文。
- 如果这个Bean关联了BeanPostProcessor接口,将会调用postProcessBeforeInitialization(Object obj, String s)方法,BeanPostProcessor经常被用作是Bean内容的更改,并且由于这个是在Bean初始化结束时调用After方法,也可用于内存或缓存技术。
- 如果这个Bean在Spring配置文件中配置了init-method属性会自动调用其配置的初始化方法。
- 如果这个Bean关联了BeanPostProcessor接口,将会调用postAfterInitialization(Object obj, String s)方法。
- 当Bean不再需要时,会经过清理阶段,如果Bean实现了DisposableBean接口,会调用其实现的destroy方法。
- 最后,如果这个Bean的Spring配置中配置了destroy-method属性,会自动调用其配置的销毁方法。
对Spring中依赖注入两种方式的认识
两种注入方式为:构造方法注入和设值注入
- 设值注入与传统的JavaBean的写法更相似,程序员更容易理解、接受,通过setter方式设定依赖关系显得更加直观、明显;
- 对于复杂的依赖关系,如果采用构造注入,会导致构造器过于臃肿,难以阅读。Spring在创建Bean实例时,需要同时实例化其依赖的全部实例,因而会产生浪费。而使用设置注入,则避免这下问题;
- 在某些属性可选的情况下,多参数的构造器更加笨拙,官方更鼓励使用设值注入。
- 构造注入可以在构造器中决定依赖关系的注入顺序,优先依赖的优先注入。
- 对于依赖关系无须变化的Bean,构造注入更有用处,因为没有setter方法,所有的依赖关系全部在构造器内设定,因此,不用担心后续代码对依赖关系的破坏。
- 构造注入使依赖关系只能在构造器中设定,则只有组件的创建者才能改变组件的依赖关系。对组件的调用者而言,组件内部的依赖关系完全透明,更符合高内聚的原则。
- 设值注入不会重写构造方法的值。如果我们对同一个变量同时使用了构造方法注入又使用了设置方法注入的话,那么构造方法将不能覆盖由设值方法注入的值。
- 建议采用以设值注入为主,构造注入为辅的注入策略。对于依赖关系无须变化的注入,尽量采用构造注入;而其他的依赖关系的注入,则考虑采用set注入。
Spring框架中都用到了哪些设计模式?
- 代理模式:在AOP和remoting中被用的比较多。
- 单例模式:在spring配置文件中定义的bean默认为单例模式。
- 模板方法模式:用来解决代码重复的问题。
- 前端控制器模式:Spring提供了DispatcherServlet来对请求进行分发。
- 依赖注入模式:贯穿于BeanFactory / ApplicationContext接口的核心理念。
- 工厂模式:BeanFactory用来创建对象的实例。
BeanFactory 和ApplicationContext的区别
BeanFactory和ApplicationContext都是接口,并且ApplicationContext是BeanFactory的子接口。
BeanFactory是Spring中最底层的接口,提供了最简单的容器的功能,只提供了实例化对象和拿对象的功能。而ApplicationContext是Spring的一个更高级的容器,提供了更多的有用的功能。
ApplicationContext提供的额外的功能:国际化的功能、消息发送、响应机制、统一加载资源的功能、强大的事件机制、对Web应用的支持等等。
加载方式的区别:BeanFactory采用的是延迟加载的形式来注入Bean;ApplicationContext则相反的,它是在Ioc启动时就一次性创建所有的Bean,好处是可以马上发现Spring配置文件中的错误,坏处是造成浪费。
大家觉得本次面试题总结的写得不错的朋友,大家可以转发+关注,然后扫描下方二维码获取更多面试题以及答案— 扫描添加暗号:【CSDN】
数据库的三大范式
1 、第一范式(1NF)
在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。
所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。
在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之,第一范式要求数据表中的每一列(每个字段)必须是不可拆分的最小单元。
2、 第二范式(2NF)
第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。
第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式要求表中的所有列,都必须依赖于主键,而不能有任何一列与主键没有关系。
3 、第三范式(3NF)
满足第三范式(3NF)必须先满足第二范式(2NF)。第三范式(3NF)要求一个数据库表中不包含其它表中已包含的非主关键字信息。简而言之,第三范式要求表中的每一列只与主键直接相关而不是间接相关,表中的每一列只能依赖于主键。
TCP和UDP的区别及其适用场景
首先说一下什么是TCP和UDP:
TCP是传输控制协议,提供的是面向连接、可靠的字节流服务。
UDP是用户数据报协议,是一个简单的面向数据报的运输层协议。
TCP和UDP的区别:
- TCP面向连接的运输层协议,UDP无连接
- TCP是可靠交付,UDP是尽最大努力交付
- TCP面向字节流,UDP面向报文
- TCP是点对点连接的,UDP一对一,一对多,多对多都可以
- TCP适合用于网页,邮件等,UDP适合用于视频,语音广播等
TCP和UDP的适用场景:
整个数据要准确无误的传递给对方,这往往用于一些要求可靠的应用,比如HTTP、HTTPS、FTP等传输文件的协议,POP、SMTP等邮件传输的协议。
当对网络通讯质量要求不高的时候,要求网络通讯速度能尽量的快,比如视频、广播等,这时就可以使用UDP。
说一下Spring的核心模块
- Spring Core【核心容器】:核心容器提供了Spring的基本功能。核心容器的核心功能是用IOC容器来管理类的依赖关系。
- Spring AOP【面向切面】:Spring的AOP模块提供了面向切面编程的支持。SpringAOP采用的是纯Java实现,采用基于代理的AOP实现方案,AOP代理由IOC容器负责生成、管理,依赖关系也一并由IOC容器管理。
- Spring ORM【对象实体映射】:提供了与多个第三方持久层框架的良好整合。
- Spring DAO【持久层模块】: Spring进一步简化DAO开发步骤,能以一致的方式使用数据库访问技术,用统一的方式调用事务管理,避免具体的实现侵入业务逻辑层的代码中。
- Spring Context【应用上下文】:它是一个配置文件,为Spring提供上下文信息,提供了框架式的对象访问方法。
- Spring Web【Web模块】:提供了基础的针对Web开发的集成特性。
- Spring MVC【MVC模块】:提供了Web应用的MVC实现。Spring的MVC框架并不是仅仅提供一种传统的实现,它提供了一种清晰的分离模型。
(转发)forward与(重定向)redirect的区别
- forward是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来,然后把这些内容再发给浏览器。浏览器根本不知道服务器发送的内容从哪里来的,所以它的地址栏还是原来的地址。
- redirect是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址,所以地址栏显示的是新的URL。
- forward转发页面和转发到的页面可以共享request里面的数据。
- redirect不能共享数据。
- redirect不仅可以重定向到当前应用程序的其他资源,还可以重定向到同一个站点上的其他应用程序中的资源,甚至是使用绝对URL重定向到其他站点的资源。
- forward只能在同一个Web应用程序内的资源之间转发请求。
- forward是服务器内部的一种操作。
- redirect是服务器通知客户端,让客户端重新发起请求。
- forward一般用于用户登陆的时候根据角色转发到相应的模块。
- redirect一般用于用户注销登陆时返回主页面和跳转到其它的网站等。
- forward效率高。
- redirect效率低。
redis常用的五种数据类型
1.String(字符串)
String是简单的 key-value 键值对,value 不仅可以是 String,也可以是数字。它是Redis最基本的数据类型,一个redis中字符串value最多可以是512M。
2.Hash(哈希)
Redis hash 是一个键值对集合,对应Value内部实际就是一个HashMap,Hash特别适合用于存储对象。
3.List(列表)
Redis 列表是简单的字符串列表,按照插入顺序排序。你可以添加一个元素导列表的头部(左边)或者尾部(右边)。
底层实现为一个双向链表,即可以支持反向查找和遍历,更方便操作,不过带来了部分额外的内存开销,Redis内部的很多实现,包括发送缓冲队列等也都是用的这个数据结构。
4.Set(集合)
Redis的Set是String类型的无序集合,它的内部实现是一个 value永远为null的HashMap,实际就是通过计算hash的方式来快速排重的,这也是set能提供判断一个成员是否在集合内的原因。
5.zset(有序集合)
Redis zset 和 set 一样也是String类型元素的集合,且不允许重复的成员,不同的是每个元素都会关联一个double类型的分数,用来排序。
内部类和静态内部类的区别
内部类:
1、内部类中的变量和方法不能声明为静态的。
2、内部类实例化:B是A的内部类,实例化B:A.B b = new A().new B()。
3、内部类可以引用外部类的静态或者非静态属性及方法。
静态内部类:
1、静态内部类属性和方法可以声明为静态的或者非静态的。
2、实例化静态内部类:B是A的静态内部类,A.B b = new A.B()。
3、静态内部类只能引用外部类的静态的属性及方法。
inner classes——内部类
static nested classes——静态嵌套类
其实人家不叫静态内部类,只是叫习惯了,从字面就很容易理解了。
内部类依靠外部类的存在为前提,而静态嵌套类则可以完全独立,明白了这点就很好理解了。
非静态内部类中的变量和方法不能声明为静态的原因
静态类型的属性和方法,在类加载的时候就会存在于内存中。使用某个类的静态属性和方法,那么这个类必须要加载到虚拟机中。但是非静态内部类并不随外部类一起加载,只有在实例化外部类之后才会加载。
我们设想一个场景:在外部类并没有实例化,内部类还没有加载的时候如果调用内部类的静态成员或方法,内部类还没有加载,却试图在内存中创建该内部类的静态成员,就会产生冲突。所以非静态内部类不能有静态成员变量或静态方法。
String,StringBuilder,StringBuffer的区别
String 字符串常量
StringBuffer 字符串变量(线程安全)
StringBuilder 字符串变量(非线程安全)
性能上通常StringBuilder > StringBuffer > String。
String是不可变对象,每次对String类型进行改变的时候都等同于生成了一个新的String对象,然后将指针指向新的String对象,所以性能最差,对于要经常改变内容的字符串不用String。
StringBuffer是字符串变量,对它操作时,并不会生成新的对象,而是直接对该对象进行更改,所以性能较好。
StringBuilder和StringBuffer一样,是字符串变量,但是他不带有synchronized关键字,不保证线程安全,所以性能最好。在单线程的情况下,建议使用StringBuilder。
总体来说:
String:适用于少量的字符串操作的情况。
StringBuilder:适用于单线程下在字符缓冲区进行大量操作的情况。
StringBuffer:适用多线程下在字符缓冲区进行大量操作的情况。
来一些问题:
下面这段代码的输出结果是什么?
|
|
输出结果为:True。
原因是String对字符串的直接相加,会在编译期进行优化。即hello+world在编译时期,被优化为helloworld,所以在运行时期,他们指向了同一个对象。我们也可以推理,对于直接字符串的相加,String不一定比其余两个慢。
下面这段代码的输出结果是什么?
|
|
输出结果为:False。
原因是c并非两个字符串直接相加,包含了一个字符串引用,这时不会做编译期的优化。所以a、c最终生成了两个对象,这时他的效率低。
集合和数组之间的相互转换
数组变集合:
通常我们会回答的是以下代码:
|
|
但这并不是很好的答案,此时组合成的list是Arrays里面的一个静态内部类,该类并未实现add、remove方法,因此在使用时存在问题。
可以这样:
|
|
集合变数组:
|
|
面向对象的特征有哪些方面?
- 抽象:抽象是将一类对象的共同特征总结出来构造类的过程,包括数据抽象和行为抽象两方面。抽象只关注对象有哪些属性和行为,并不关注这些行为的细节是什么。
- 继承:继承是从已有类得到继承信息创建新类的过程。提供继承信息的类被称为父类;得到继承信息的类被称为子类。继承让变化中的软件系统有了一定的延续性,同时继承也是封装程序中可变因素的重要手段。
- 封装:通常认为封装是把数据和操作数据的方法绑定起来,对数据的访问只能通过已定义的接口。面向对象的本质就是将现实世界描绘成一系列完全自治、封闭的对象。我们在类中编写的方法就是对实现细节的一种封装;我们编写一个类就是对数据和数据操作的封装。可以说,封装就是隐藏一切可隐藏的东西,只向外界提供最简单的编程接口。
- 多态性:多态性是指允许不同子类型的对象对同一消息作出不同的响应。简单的说就是用同样的对象引用调用同样的方法但是做了不同的事情。多态性分为编译时的多态性和运行时的多态性。方法重载实现的是编译时的多态性,而方法重写实现的是运行时的多态性。
概括的解释下线程的几种状态
- 就绪(Runnable):线程准备运行,不一定立马就能开始执行。
- 运行中(Running):进程正在执行线程的代码。
- 等待中(Waiting):线程处于阻塞的状态,等待外部的处理结束。
- 睡眠中(Sleeping):线程被强制睡眠。
- I/O阻塞(Blocked on I/O):等待I/O操作完成。
- 同步阻塞(Blocked on Synchronization):等待获取锁。
- 死亡(Dead):线程完成了执行。
Java集合类里面基本的接口有哪些
- Collection:代表一组对象,每一个对象都是它的子元素。
- Set:不包含重复元素的Collection。
- List:有顺序的collection,并且可以包含重复元素。
- Map:可以把键(key)映射到值(value)的对象,键不能重复。
Iterator和ListIterator的区别
- Iterator可用来遍历Set和List集合,但是ListIterator只能用来遍历List。
- Iterator对集合只能是前向遍历,ListIterator既可以前向遍历也可以后向遍历。
- ListIterator实现了Iterator接口,并包含其他的功能,比如:增加、替换元素,获取前一个和后一个元素的索引等等。
Enumeration和Iterator的区别
- java中的集合类都提供了返回Iterator的方法,就是迭代器,它和Enumeration(枚举)的主要区别其实就是Iterator可以删除元素,但是Enumration却不能。
- 使用Iterator来遍历集合时,应使用Iterator的remove()方法来删除集合中的元素,使用集合的remove()方法将抛出ConcurrentModificationException异常。
- Enumeration接口的功能和Iterator接口的功能是重复的。此外,Iterator 接口添加了一个可选的移除操作,并使用较短的方法名。新的实现应该优先考虑使用Iterator接口而不是Enumeration接口。
- Enumeration速度是Iterator的2倍,同时占用更少的内存。但是,Iterator远远比Enumeration安全,因为其他线程不能够修改正在被iterator遍历的集合里面的对象。
大家觉得本次面试题总结的写得不错的朋友,大家可以转发+关注,然后扫描下方二维码获取更多面试题以及答案— 扫描添加暗号:【CSDN】
介绍一下HTTP的响应结构
请求报文的组成:
- 请求方法。
- 请求的资源的URI。
- 协议版本。
- 可选的请求首部字段。
- 内容实体。
响应报文的组成:
- 协议版本。
- 状态码。
- 用于解释状态码的原因短语。
- 可选的响应首部字段。
- 实体主体。
响应:
- 响应码:回应客户端此次响应是否成功。如:404(找不到请求的资源),500(服务器内部错误),200(成功响应)等。
- 消息头:服务器与客户端通信的暗码,告诉客户端该怎么执行某些操作。
- 响应正文:传递服务器响应给客户端要显示的内容,可以是下载文件或者显示界面。
final、finalize和finally各自的作用
final是一个修饰符,可以修饰变量、方法和类。如果 final 修饰变量,意味着该变量的值在初始化后不能被改变。
finalize方法是在对象被回收之前调用的方法,给对象自己最后一个复活的机会,但是什么时候调用 finalize 没有保证。
finally是一个关键字,与try和catch一起用于异常的处理。finally块一定会被执行,无论在try块中是否有发生异常。
说一下你了解的几种进程间的通信方式
- 管道pipe:管道是一种半双工的通信方式,数据只能单向流动,而且只能在具有亲缘关系的进程间使用。进程的亲缘关系通常是指父子进程关系。
- 高级管道popen:将另一个程序当做一个新的进程在当前程序进程中启动,则它算是当前程序的子进程,这种方式我们成为高级管道方式。
- 有名管道named pipe :有名管道也是半双工的通信方式,但是它允许无亲缘关系进程间的通信。
- 消息队列MessageQueue:消息队列是由消息的链表,存放在内核中并由消息队列标识符标识。消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。
- 共享存储SharedMemory:共享内存就是映射一段能被其他进程所访问的内存,这段共享内存由一个进程创建,但多个进程都可以访问。共享内存是最快的 IPC 方式,它是针对其他进程间通信方式运行效率低而专门设计的。它往往与其他通信机制,如信号两,配合使用,来实现进程间的同步和通信。
- 信号量Semaphore:信号量是一个计数器,可以用来控制多个进程对共享资源的访问。它常作为一种锁机制,防止某进程正在访问共享资源时,其他进程也访问该资源。因此,主要作为进程间以及同一进程内不同线程之间的同步手段。
- 套接字Socket:套解口也是一种进程间通信机制,与其他通信机制不同的是,它可用于不同及其间的进程通信。
- 信号sinal: 信号是一种比较复杂的通信方式,用于通知接收进程某个事件已经发生。
以上便是此次分享的面试题以及答案,如果觉得还不过瘾,大家可以关注我的公众号-【Java烂猪皮】,里面有往期的面试题以及最新的面试分享,关注后回复:【666】即可免费获取更多的Java架构进阶vip学习资料