最多见的Java面试题及答案汇总（五）

Java Web

64. jsp 和 servlet 有什么区别？

1. jsp经编译后就变成了Servlet.（JSP的本质就是Servlet，JVM只能识别java的类，不能识别JSP的代码，Web容器将JSP的代码编译成JVM可以识别的java类）

2. jsp更擅长表现于页面显示，servlet更擅长于逻辑控制。

3. Servlet中没有内置对象，Jsp中的内置对象都是必须经过HttpServletRequest对象，HttpServletResponse对象以及HttpServlet对象获得。

4. Jsp是Servlet的一种简化，使用Jsp只须要完成程序员须要输出到客户端的内容，Jsp中的Java脚本如何镶嵌到一个类中，由Jsp容器完成。而Servlet则是个完整的Java类，这个类的Service方法用于生成对客户端的响应。

 

65. jsp 有哪些内置对象？做用分别是什么？

JSP有9个内置对象：

• request：封装客户端的请求，其中包含来自GET或POST请求的参数；

• response：封装服务器对客户端的响应；

• pageContext：经过该对象能够获取其余对象；

• session：封装用户会话的对象；

• application：封装服务器运行环境的对象；

• out：输出服务器响应的输出流对象；

• config：Web应用的配置对象；

• page：JSP页面自己（至关于Java程序中的this）；

• exception：封装页面抛出异常的对象。

66. 说一下 jsp 的 4 种做用域？

JSP中的四种做用域包括page、request、session和application，具体来讲：

• page表明与一个页面相关的对象和属性。

• request表明与Web客户机发出的一个请求相关的对象和属性。一个请求可能跨越多个页面，涉及多个Web组件；须要在页面显示的临时数据能够置于此做用域。

• session表明与某个用户与服务器创建的一次会话相关的对象和属性。跟某个用户相关的数据应该放在用户本身的session中。

• application表明与整个Web应用程序相关的对象和属性，它实质上是跨越整个Web应用程序，包括多个页面、请求和会话的一个全局做用域。

67. session 和 cookie 有什么区别？

• 因为HTTP协议是无状态的协议，因此服务端须要记录用户的状态时，就须要用某种机制来识具体的用户，这个机制就是Session.典型的场景好比购物车，当你点击下单按钮时，因为HTTP协议无状态，因此并不知道是哪一个用户操做的，因此服务端要为特定的用户建立了特定的Session，用用于标识这个用户，而且跟踪用户，这样才知道购物车里面有几本书。这个Session是保存在服务端的，有一个惟一标识。在服务端保存Session的方法不少，内存、数据库、文件都有。集群的时候也要考虑Session的转移，在大型的网站，通常会有专门的Session服务器集群，用来保存用户会话，这个时候 Session 信息都是放在内存的，使用一些缓存服务好比Memcached之类的来放 Session。

• 思考一下服务端如何识别特定的客户？这个时候Cookie就登场了。每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的，第一次建立Session的时候，服务端会在HTTP协议中告诉客户端，须要在 Cookie 里面记录一个Session ID，之后每次请求把这个会话ID发送到服务器，我就知道你是谁了。有人问，若是客户端的浏览器禁用了 Cookie 怎么办？通常这种状况下，会使用一种叫作URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数，服务端据此来识别用户。

• Cookie其实还能够用在一些方便用户的场景下，设想你某次登录过一个网站，下次登陆的时候不想再次输入帐号了，怎么办？这个信息能够写到Cookie里面，访问网站的时候，网站页面的脚本能够读取这个信息，就自动帮你把用户名给填了，可以方便一下用户。这也是Cookie名称的由来，给用户的一点甜头。因此，总结一下：Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据能够保存在集群、数据库、文件中；Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。

 

68. 说一下 session 的工做原理？

其实session是一个存在服务器上的相似于一个散列表格的文件。里面存有咱们须要的信息，在咱们须要用的时候能够从里面取出来。相似于一个大号的map吧，里面的键存储的是用户的sessionid，用户向服务器发送请求的时候会带上这个sessionid。这时就能够从中取出对应的值了。

 

69. 若是客户端禁止 cookie 能实现 session 还能用吗？

Cookie与 Session，通常认为是两个独立的东西，Session采用的是在服务器端保持状态的方案，而Cookie采用的是在客户端保持状态的方案。但为何禁用Cookie就不能获得Session呢？由于Session是用Session ID来肯定当前对话所对应的服务器Session，而Session ID是经过Cookie来传递的，禁用Cookie至关于失去了Session ID，也就得不到Session了。

假定用户关闭Cookie的状况下使用Session，其实现途径有如下几种：

1. 设置php.ini配置文件中的“session.use_trans_sid = 1”，或者编译时打开打开了“--enable-trans-sid”选项，让PHP自动跨页传递Session ID。

2. 手动经过URL传值、隐藏表单传递Session ID。

3. 用文件、数据库等形式保存Session ID，在跨页过程当中手动调用。

 

70. spring mvc 和 struts 的区别是什么？

• 拦截机制的不一样

Struts2是类级别的拦截，每次请求就会建立一个Action，和Spring整合时Struts2的ActionBean注入做用域是原型模式prototype，而后经过setter，getter吧request数据注入到属性。Struts2中，一个Action对应一个request，response上下文，在接收参数时，能够经过属性接收，这说明属性参数是让多个方法共享的。Struts2中Action的一个方法能够对应一个url，而其类属性却被全部方法共享，这也就没法用注解或其余方式标识其所属方法了，只能设计为多例。

SpringMVC是方法级别的拦截，一个方法对应一个Request上下文，因此方法直接基本上是独立的，独享request，response数据。而每一个方法同时又何一个url对应，参数的传递是直接注入到方法中的，是方法所独有的。处理结果经过ModeMap返回给框架。在Spring整合时，SpringMVC的Controller Bean默认单例模式Singleton，因此默认对全部的请求，只会建立一个Controller，有应为没有共享的属性，因此是线程安全的，若是要改变默认的做用域，须要添加@Scope注解修改。

Struts2有本身的拦截Interceptor机制，SpringMVC这是用的是独立的Aop方式，这样致使Struts2的配置文件量仍是比SpringMVC大。

• 底层框架的不一样

Struts2采用Filter（StrutsPrepareAndExecuteFilter）实现，SpringMVC（DispatcherServlet）则采用Servlet实现。Filter在容器启动以后即初始化；服务中止之后坠毁，晚于Servlet。Servlet在是在调用时初始化，先于Filter调用，服务中止后销毁。

• 性能方面

Struts2是类级别的拦截，每次请求对应实例一个新的Action，须要加载全部的属性值注入，SpringMVC实现了零配置，因为SpringMVC基于方法的拦截，有加载一次单例模式bean注入。因此，SpringMVC开发效率和性能高于Struts2。

• 配置方面

spring MVC和Spring是无缝的。从这个项目的管理和安全上也比Struts2高。

 

71. 如何避免 sql 注入？

1. PreparedStatement（简单又有效的方法）

2. 使用正则表达式过滤传入的参数

3. 字符串过滤

4. JSP中调用该函数检查是否包函非法字符

5. JSP页面判断代码

 

72. 什么是 XSS 攻击，如何避免？

XSS攻击又称CSS,全称Cross Site Script  （跨站脚本攻击），其原理是攻击者向有XSS漏洞的网站中输入恶意的 HTML 代码，当用户浏览该网站时，这段 HTML 代码会自动执行，从而达到攻击的目的。XSS 攻击相似于 SQL 注入攻击，SQL注入攻击中以SQL语句做为用户输入，从而达到查询/修改/删除数据的目的，而在xss攻击中，经过插入恶意脚本，实现对用户游览器的控制，获取用户的一些信息。 XSS是 Web 程序中常见的漏洞，XSS 属于被动式且用于客户端的攻击方式。

XSS防范的整体思路是：对输入(和URL参数)进行过滤，对输出进行编码。

 

73. 什么是 CSRF 攻击，如何避免？

CSRF（Cross-site request forgery）也被称为 one-click attack或者 session riding，中文全称是叫跨站请求伪造。通常来讲，攻击者经过伪造用户的浏览器的请求，向访问一个用户本身曾经认证访问过的网站发送出去，使目标网站接收并误觉得是用户的真实操做而去执行命令。经常使用于盗取帐号、转帐、发送虚假消息等。攻击者利用网站对请求的验证漏洞而实现这样的攻击行为，网站可以确认请求来源于用户的浏览器，却不能验证请求是否源于用户的真实意愿下的操做行为。

如何避免：

1. 验证 HTTP Referer 字段

HTTP头中的Referer字段记录了该 HTTP 请求的来源地址。在一般状况下，访问一个安全受限页面的请求来自于同一个网站，而若是黑客要对其实施 CSRF
攻击，他通常只能在他本身的网站构造请求。所以，能够经过验证Referer值来防护CSRF 攻击。

2. 使用验证码

关键操做页面加上验证码，后台收到请求后经过判断验证码能够防护CSRF。但这种方法对用户不太友好。

3. 在请求地址中添加token并验证

CSRF 攻击之因此可以成功，是由于黑客能够彻底伪造用户的请求，该请求中全部的用户验证信息都是存在于cookie中，所以黑客能够在不知道这些验证信息的状况下直接利用用户本身的cookie 来经过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，而且该信息不存在于 cookie 之中。能够在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端创建一个拦截器来验证这个 token，若是请求中没有token或者 token 内容不正确，则认为多是 CSRF 攻击而拒绝该请求。这种方法要比检查 Referer 要安全一些，token 能够在用户登录后产生并放于session之中，而后在每次请求时把token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。
对于 GET 请求，token 将附在请求地址以后，这样 URL 就变成 http://url?csrftoken=tokenvalue。
而对于 POST 请求来讲，要在 form 的最后加上 <input type="hidden" name="csrftoken" value="tokenvalue"/>，这样就把token以参数的形式加入请求了。

4. 在HTTP 头中自定义属性并验证

这种方法也是使用 token 并进行验证，和上一种方法不一样的是，这里并非把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。经过 XMLHttpRequest 这个类，能够一次性给全部该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，经过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担忧 token 会透过 Referer 泄露到其余网站中去。