01Javaweb面试题集答案.docx

《01Javaweb面试题集答案.docx》由会员分享，可在线阅读，更多相关《01Javaweb面试题集答案.docx（4页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、Javaweb面试题及答案L说下原生JDBC操作数据库流程？第一步：Class.forNameO加载数据库连接驱动；第二步:DriverManager.getConnectionO获取数据连接对象； 第三步：根据SQL获取sql会话对象，有2种方式Statement. PreparedStatement;第四步：执行SQL,执行SQL前如果有参数值就设西参数值setXXXQ; 第五步：处理结果集；第六步：关闭结果集、关闭会话、关闭连接。2、为什么要使用 PreparedStatement ?PreparedStatement接口继承Statement, PreparedStatement实例包

2、含已编译的SQL语句，所以其执行速度要快于Statement对 象.作为 Statement 的子类，PreparedStatement 继承了 Statement 的所有功能。三种方法 execute、executeQuery 和 executeUpdate 已被更改以使之不再需要参数. 在JDBC应用中，多数情况下使用PreparedStatement,原因如下：代码的可读性和可维护性.Statement需要不断地拼接，而PreparedStatement不会.PreparedStatement尽最大可能提高性能.DB有缓存机制，相同的预编深语句再次被调用不会再次需要编译.最重变的一点是极

3、大地提高了安全性。Statement容易被SQL注入，而PreparedStatement传入的内容不会和sql语句发生任何匹配 关系.3、 的长连接和短连接区别？ 协议有 /1.0版本和 /1.1版本. 1.1默认保持长连接( persistent connection ,也翻译为持久连接)，数 据传输完成了保持TCP连接不断开(不发RST包、不四次握手)，等待在同域名下继续用这个通道传输数据；相反的就是短连接.在 /1.0中，默认使用的是短连接.也就是说，浏览器和服务器每进行一次 操作，就建立一次连接，任务结束就中断连接.从 /1.1起，默认使用的是长连接，用以保持连接特性.4. /1.1

4、 与 /1.0 的区别？可扩展性 /L1在消息中增加版本号，用于兼容性判断。 HRP/1.1增加了 OPTIONS方法，它允许客户端获取一个服务器支持的方法列衷.为了与未来的协议规范兼容，HUP/1.1在请求消息中包含了 Upgrade头域，通过该头域，客户端可以让服务器知道它能够支持的具 它备用通信协议，服务器可以据此进行协议切换，使用备用协设与客户端进行通信.缓存在 /1.0中使用Expire头域来判断资源的fresh或stale并使用条件请求conditional request原判断资源是否仍有效。 /1.1 在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expi

5、re时变为stale对象，cache不需要亘接抛弃stale对象，而 是与源服务器进行更新激活(revalidation ).带宽优化HUP/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一局部，而服务器却将整个对象送过来了,例如，客户端只需 要显示一个文档的局部内容，又比方下载大文件时需要支持断点续传功能，而不是在发生断连后不得不里新下载完整的包. /L1中在请求消息中引入了 range头域,它允许只请求资源的某个局部.在响应消息中Content-Range头域声明了返回的这局部 对象的偏移值和长度.如果I员务器相应地返回了对象所请求范围的内容，那么响应码为206 ( Par

6、tial Content),它可以防止Cache将响 应误以为是完型的一个对象，另夕1种情况是请求消息中如果包含比拟大的实体内容，但不确定务器是否能够接收该请求(如是否有权限),此时假设贸然发出带实 体的请求，如果被拒绝也会浪费带宽.HRP/1.1加入了一个新的状态码100 ( Continue ).客户端事先发送一个只带头域的请求，如 果服务器因为权限拒绝了请求，就回送响应码401 ( Unauthorized );如果服务器接收此请求就回送响应码100 ,客户端就可以继续发 送带实体的完整请求了.注意， /1.0的客户端不支持100响应码.但可以让客户端在请求消息中加入Expect头域，并

7、将它的值设置为100-continue.节 省带宽资源的一个非常有效的做法就是压缩要传送的数据.Content-Encoding是对消息进行端到端(end-to-end )的编码，它可能是 资源在服务器上保存的固有格式(如jpeg图片格式)；在请求消息中加入Accept-Encoding头域，它可以告诉服务器客户端能够解码 的编码方式.长连接 /L0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即 断开TCP连接服务器不跟踪每个客户也不记录过去的请求.此外，由于大多数网页的流量都比拟小，一次TCP连接很少能通过slow-start

8、区,不利于提高带宽利用率。 1.1支持长连接(PersistentConnection )和请求的流水线(Pipelining )处理,在一个TCP连接上可以传送多个 请求和 呜应，减少了建立和关闭连接的消楸口延迟。例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个 单独的网页文件的请求和应答仍然需要使用各自的连接. 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，回员务器端必须按照接收到客户端请求的先后顺序依次 回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间.消息传递 消息中可以包含任过长度的

9、实体，通常它们使用Content-Length来给出消息结束标志。但是，对于很多动态产生的响应，只能 通过缓冲完整的消息来判断消息的大小，但这样做会加大延迟,如果不使用长连接，还可以通过连接关闭的信号来判定一个消息的结束. /1.1中引入了 Chunkedtransfer-coding来解决上面这个问题，发送方将消息分割成假设干个任意大的数据块，每个数据块在发送 时都会附上块的长度，最后用一个零长度的块作为消息结束的标志.这种方法允许发送方只缓冲消息的一个片段，防止缓冲整个消息带 来的过载.在 /L0中，有一个Content-MDS的头域，要计算这个头域需要发送方缓冲完整个消息后才能进行.而

10、/1.1中采用chunked 分块传递的消息在最后一个块(零长度)结束之后会再传递一个拖尾(trailer),它包含一个或多个头域，这些头域是发送方在传递完所 有块之后再计箕出值的.发送方会在消息中包含一个Trailer头域告诉接收方这个拖尾的存在. Host头域在 L0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名(hostname ).但随着虚拟主 机技术的开展，在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers ),并且它们共享一个IP地址. L1的 请求消息和响应消息都应支持Host头域，且请求消息中如果没有Hos

11、t头域会报告一个靖误(400 Bad Request).此外,服务器应 该接受以绝对路径标记的资源请求.错误提示HUP/1.0中只定义了 16个状态响应码，对错误或警告的提示不够具体。 /1.1引入了一个Warning头域，增加对错误或警告信 息的描述.此外，在 /1.1中新增了 24个状态响应码，如409( Conflict)表示请求的资源与资源的当前状态发生冲突;410( Gone ) 表示服务据上的某个资源被永久性的删除.5、 常见的状态码有哪些？ 200 0K客户端请求成功301Moved Permanently (永久移除),请求的URL已移走。Response中应该包含Locati

12、on URL ,说明资源现在所处的位置 302found重定向 400Bad Request客户端请求有语法错误，不能被服务器所理解401Unauthorized请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 403 Forbidden服务器收到请求，但是拒绝提供服务404 Not Found请求资源不存在，eg :输入了错误的URL 500 Internal Server Error服务gg发生不可预期的1自误503 Server Unavailable服务器当前不能处理客户端的请求,一段时间后可能恢且正常6、GET和POST的区别？ GET请求的数据会附在U

13、RL之后（就是把数据放置在 协议头中）,以?分割URL和传谕数据，参数之间以&相连，如： login.action?name=zhagnsan&password=123456. POST 把提交的数据那么放音在是 包的包体中. GET方式提交的数据最多只能是1024字节，理论上POST没有限制，可传较大量的数据.其实这样说是错误的，不准确的：GET 方式提交的数据最多只能是1024字节，因为GET是通过URL提交数据，另法GET可提交的数据量就跟URL的长度有直接关系了. 而实际上，URL不存在参数上限的问题， 协议规范没有对URL长度进行限制.这个限制是特定的浏览器及服务器对它的限制.正 对

14、URL长度的限制是2083字节（2K+35）.对于其他浏览器,如Netscape. FireFox等，理论上没有长度限制，其限制取决于掾作系统 的支持. POST的安全性要比GET的安全性高.注意：这里所说的安全性和上面GET提到的安全”不是同个概念。上面安全”的含义仅 仅是不作数据修改，而这里安全的含义是真正的Security的含义，比方：通过GET提交数据，用户名和密码将明文出现在URL上，因 为登录页面有可能被浏览器缓存，其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和空码了，除此之外，使用GET提交 数据还可能会造成Cross-site request forgery攻击. G

15、et是向服务器发索取数据的一种请求，而Post是向服务器提交数据的一种请求，在FORM （表单）中，Method默认为“GE, 实质上GET和POST只是发送机制不同，并不是一个取一个发.7、 中重定向和谙求转发的区别？本质区别：转发是I艮务器行为，变定向是客户端行为.否认向特点：两次请求，浏览器地址发生变化，可以访问自己web之外的资源，传输的数据会丧失.请求转发特点：一次强求，浏览器地址不变，访问的是自己本身的web资源，传输的数据不会丧失.8、Cookie 和 Session 的区别?Cookie是web服务器发送给浏览器的一块信息，浏览器会在本地一个文件中给每个web服务器存储Cook

16、ie.以后浏览甥再给特定的 web服务器发送请求时，同时会发送所有为该服务器存储的Cookie.Session是存储在web服务器端的一块信息.Session对象存储特定用户会话所需的属性及配置信息.当用户在应用程序的Web页之 间，篦时，存储在Session对象中的变量将不会丧失，而是在整个用户会话中一直存在下去. Cookie和Session的不同点:无论客户端做怎样的设爸,Session都能够正常工作.当客户端禁用Cookie时将无法使用Cookie.在存储的数据量方面：Session能够存悌任意的java对象，Cookie只能存储String类型的对象.9、2.session共享怎么做

17、的（分布式如何实现session共享）？问题描述：一个用户在登录成功以后会把用户信息存储在session当中，这时session所在服务器为serveri ,刃及用户在session失效 之前如果再次使用app ,刃彩可能会被路由到server2,这时问题来了，server2没有该用户的session ,所以需要用户或新登录，这时 的用户体验会非常不好，所以我们想如何实现多台server之间共享session ,让用户状态得以保存。服务器实现的session豆制或session共享，这类型的共享session是和服务器紧密相关的，比方WebSphere或JBOSS在搭建集群 时候可以配置实现s

18、ession豆制或session共享，但是这种方式有一个致命的缺点,就是不好扩展和移植,比方我们更换服务器,那么 就要修改服务器配置.利用成熟的技术session复制，比方12306使用的gemfire，比方常见的内存数据库如redis或memorycache ,这类方案虽然比拟 普适，但是严重依赖于第三方，这样当第三方服务器出现问题的时候，那么将是应用的灾难.将session维护在客户端，很容易想到就是利用cookie，但是客户端存在风险,数据不安全，而且可以存放的数据幽戚小,所以将 session维护在客户端还要对session中的信息加密.我们实现的方案可以说是第二种方案和第三种方案的合

19、体，可以利用gemfire实 现session豆制共享，还可以session维护在redis中实现session共享，同时可以将session维护在客户端的cookie中，但是前提是 数据要加密。这三种方式可以迅速切换，而不影响应用正常执行.我们在实践中，首选gemfire或者redis作为session共享的载体， 一旦session不稳定出现问题的时候，可以紧急切换cookie维护session作为备用，不影响应用提供服务.这里主要讲解redis和cookie方案，gemfire匕嫩复杂大家可以自行查看gemfire工作原理.利用redis做session共享，首先需要与 业务逻担代码解酒

20、,不然session共享将没有意义，其次支持动态切换到客户端cookie模式redis的方案是，至写服务器中的 Session 和 ServletRequest,首卷t现 Session 接口，重写 session 的所有方法，格 session 以 hash 值的方式存在 redis 中，一个session的key就是sessionlD , setAtrribute至写之后就是更新redis中的数据,getAttribute *写之后就是驶取redis中的 数据,等等需要将 Session的接口一实现.实现了 Sesson ,那么我们先将该session类叫做MySession （当然实践中

21、不是 这么命名的），当MySession出现之后问题才开始，怎么能在不影响业务逻娼代码的情况下,还能让原本的request.getSession。获取 到的是MySession ,而不是服务器原生的session.这里,我决定歪写服务器的 ServletRequet,这里先称为MyRequest,但是这 可不是单纯的重写，我需要在原生的request基础上重写，于是我决定在filter中，实现request的愉梁换柱，我的思路是这样的, MyRequest的构建器，必须以request作为参数，于是我在filter中将服务器原生的request （也有可能是框架封装过的request）, 当做

22、参数new出来一个MyRequest,并且MyRequest降现了 ServletRequest接口，其实就是对原生request的f 增强， 这里主要更写了几个request的方法，但是最重要的是至写了 request.getSessionQ ,写到这里大家应该都明白为什么歪写这个方法了 吧，当然是为了获取MySession ,于是这样就在filter中，偷价的将原生的request换成MyRequest 了 ,然后再将替换过的request 传入chan.doFilter（）,这样filter时候的代码都使用的是MyRequest 了，同时对业务代码是透明的，业务代码获取session的方

23、法仍然 是request.getSessionQ，但其实获取到的已经是MySession 了 ,这样对session的操作已经变成了对redis的操作.这样实现的好处 有两个，第一开发人员不需要对session共享做任何关注，session共享对用户是透明的；第二,filter是可配置的，通过filter的方式 可以将session共享做成一项可插拔的功能，没有任何侵入性.这个时候已经实现了一套可插拔的session共享的框架了，但是我们想 到如果redis服务出了问题，这时我们该怎么办呢，于是我们延续redis的想法，想到可以将session维护在客户端内（加密的cookie ）, 当然实现

24、方法还是一样的，我们全写 Session接口，实现其所有方法，比方setAttribute就是写入cookie , getAttribute就是读 取cookie ,我们可以将重写的session称作MySession2 ,这时怎么让开发人员透明的获取到MySession2呢，实现方法还是在filter 内偷梁换住，在MyRequest加一个判断，读取sessionType配置,如果sessionType是redis的,另及 getSession的时候获取到的 是MySession ,如果sessionType是coolie的，那么getSession的时候获取到的是MySession2 ,以

25、此类推，用同样的方法就可以获 崛 MySession3.4,5,6 等等.这样两种方式都有了，那么我们怎实现两种session共享方式的快速切换呢刚刚我提到T sessionType这是用来决定获取到session 的类型的，只要变换sessionType就能实现两种session共享方式的切换，但是sessionType必须对所有的服务器都是一致的，如果不 一致月豳会出现比拟严歪的问题.我们目前是将sessionType维沪在环境变量里，如果要切换sessionType就要更启每一台服务器，完 成session共享的转换，但是当服务器太多的时候将是一种灾难,而且重启服务意味着服务的中断，所以

26、这样的方式只适合服务器规模 比拟小，而且用户量比拟少的情况，当服务器太多的时候，务必需要一种协调技术，能够让服务器能够及时获取切换的通知.基于这样 的原因，我们选用zookeeper作为配置平台，每一台服务器都会订阅zookeeper上的配置，当我们切换sessionType之后，所有服务 器都会订阅到修改之后的配置,那么切换就会立即生效，当然可能会有短暂的时间延迟，但这是可以接受的.10.在单点登录中，如果cookie被禁用了怎么办？单点登录的原理是后端生成一个sessionlD ,然后设置到cookie ,后面的所有请求浏览器都会带上cookie ,然后服务端从cookie里获 取sessionlD ,再查询到用户信息.所以，保持登录的关犍不是cookie ,而是通过cookie保存和传输的sessionlD ,其本质是能获取用 户信息的数据.除了 cookie,还通常使用 请求头来传输.但是这个请求头浏览器不会像cookie一样自动携带，需要手工处理.