抽象类和接口的区别,类能够继承多个类吗,接口能够继承多个接口吗,类能够实现多个接口吗?mysql
抽象类和接口都不能直接实例化,若是要实例化,抽象类变量必须指向实现全部抽象方法的子类对象,接口变量必须指向实现全部接口方法的类对象。 web
抽象类要被子类继承,接口要被类实现。
redis
接口只能作方法声明,抽象类中能够作方法声明,也能够作方法实现
sql
接口里定义的变量只能是公共的静态的常量,抽象类中的变量是普通变量。
数据库
抽象类里的抽象方法必须所有被子类所实现,若是子类不能所有实现父类抽象方法,那么该子类只能是抽象类。一样,一个实现接口的时候,如不能所有实现接口方法,那么该 类也只能为抽象类。
设计模式
抽象方法只能申明,不能实现。abstract void abc();不能写成abstract void abc(){}。
浏览器
抽象类里能够没有抽象方法 。
缓存
若是一个类里有抽象方法,那么这个类只能是抽象类 。
安全
抽象方法要被实现,因此不能是静态的,也不能是私有的。
服务器
接口可继承接口,并可多继承接口,但类只能单根继承。
Tomcat,Apache,Jboss的区别?
Tomcat是servlet容器,用于解析jsp,servlet。是一个轻量级的高效的容器;缺点是不支持EJB,只能用于Java应用。
Apache是http服务器(web服务器),相似于IIS能够用来创建虚拟站点,编译处理静态页面。支持SSL技术,支持多个虚拟主机等功能。
Jboss是应用服务器,运行EJB的Javaee应用服务器,遵循Javaee规范,可以提供更多平台的支持和更多集成功能,如数据库链接,JCA等。其对servlet的支持是经过集成其余servlet容器来实现的。
说出Servlet的生命周期,并说出Servlet和CGI的区别。
Servlet被服务器实例化后,容器运行其init方法,请求到达时运行其service方法,service方法自动派遣运行与请求对应的doXXX方法(doGet,doPost)等,当服务器决定将实例销毁的时候调用其destroy()方法。
与CGI的区别在于Servlet处于服务器进程中,它经过多线程方式运行其service方法,一个实例能够服务于多个请求,而且其实例通常不会销毁,而CGI对每一个请求都产生新的进程,服务完成后就销毁,因此效率上低于Servlet。
谈谈你对MVC的理解
MVC是Model—View—Controler的简称。即模型—视图—控制器。MVC是一种设计模式,它强制性的把应用程序的输入、处理和输出分开。
MVC中的模型、视图、控制器它们分别担负着不一样的任务。
视图: 视图是用户看到并与之交互的界面。视图向用户显示相关的数据,并接受用户的输入。视图不进行任何业务逻辑处理。
模型: 模型表示业务数据和业务处理,至关于JavaBean。一个模型能为多个视图提供数据。这提升了应用程序的重用性。
控制器: 当用户单击Web页面中的提交按钮时,控制器接受请求并调用相应的模型去处理请求,而后根据处理的结果调用相应的视图来显示处理的结果。
MVC的处理过程:首先控制器接受用户的请求,调用相应的模型来进行业务处理,并返回数据给控制器。控制器调用相应的视图来显示处理的结果。并经过视图呈现给用户。
如何避免浏览器缓存?
HTTP信息头中包含Cache-Control:no-cache,pragma:no-cache,或Cache-Control:max-age=0等设置浏览器不用缓存请求。
须要根据Cookie,认证信息等决定输入内容的动态请求是不能被缓存的。
通过HTTPS安全加密的请求不能被缓存。
HTTP响应头中不包含Last-Modified/Etag,也不包含Cache-Control/Expires的请求没法被缓存 。
如何防止缓存雪崩?
缘由:
缓存雪崩多是由于数据未加载到缓存中,或者缓存同一时间大面积的失效,从而致使全部请求都去查数据库,致使数据库CPU和内存负载太高,甚至宕机。
对应解决:
采用加锁计数,或者使用合理的队列数量来避免缓存失效时对数据库形成太大的压力。这种办法虽然能缓解数据库的压力,可是同时又下降了系统的吞吐量。
分析用户行为,尽可能让失效时间点均匀分布。避免缓存雪崩的出现。
若是是由于某台缓存服务器宕机,能够考虑作主备,好比:redis主备,可是双缓存涉及到更新事务的问题,update可能读到脏数据,须要好好解决。
数据库会死锁吗,举一个死锁的例子,mysql 怎么解决死锁。
产生死锁的缘由主要是:
系统资源不足。
进程运行推动的顺序不合适。
资源分配不当等。
若是系统资源充足,进程的资源请求都可以获得知足,死锁出现的可能性就很低,不然就会因争夺有限的资源而陷入死锁。其次,进程运行推动顺序与速度不一样,也可能产生死锁。
产生死锁的四个必要条件:
互斥条件:一个资源每次只能被一个进程使用。
请求与保持条件:一个进程因请求资源而阻塞时,对已得到的资源保持不放。
不剥夺条件:进程已得到的资源,在末使用完以前,不能强行剥夺。
循环等待条件:若干进程之间造成一种头尾相接的循环等待资源关系。
这四个条件是死锁的必要条件,只要系统发生死锁,这些条件必然成立,而只要上述条件之一不知足,就不会发生死锁。
解决数据库死锁的方法:
重启数据库。
杀掉抢资源的进程。
Dubbo源码使用了哪些设计模式?
工厂模式:
ExtenstionLoader.getExtenstionLoader(Protocol.class).getAdaptiveExtenstion()
装饰器模式+责任链:
以provider的调用链为例,具体调用链代码是在protocolFilterWrapper的buildInvokeChain完成的,将注解中含有group=provider的Filter实现。
调用顺序:
EchoFilter
ClassLoaderFilter
GenericFilter
ContextFilter
ExceptionFilter
TimeoutFilter
MonitorFilter
TraceFilter
装饰器模式和责任链混合使用,Echo是回声测试请求,ClassLoaderFilter则只是在其主功能上添加了功能。
观察者模式:
provider启动时须要与注册中心交互,先注册本身的服务,再订阅本身的服务,订阅时采用了观察者模式,注册中心每5s定时检查是否有服务更新,有更新则向服务提供者发送1个notify消息后便可运行NotifyListener的notity方法,执行监听器方法。
动态代理模式:
扩展JDK的ExtensionLoaderdeAdaptive实现,根据调用阶段动态参数决定调用哪一个类,生成代理类的代码是ExtensionLoader的createAdaptiveExtenstionClassLoader方法。