Java 之 Java Web【Java面试题】(1)

2401_84002271

已于 2024-04-28 21:31:55 修改

阅读量171

点赞数 4

分类专栏：程序员文章标签： java 前端开发语言

于 2024-04-28 21:31:54 首次发布

本文链接：https://blog.csdn.net/2401_84002271/article/details/138291967

版权

程序员专栏收录该内容

205 篇文章 0 订阅

订阅专栏

在当前页面和当前页面中的标签共享数据：

void setAttribute(String name, Object value)；

Object getAttrbiute(String name, Object value)；

void removeAttribute(String name, Object value)；

全域： pageContext.findAttribute(“内容”)在四个域中搜索数据

自动搜索数据顺序:page域->request域->session域->application域(context域)

其他的和Servlet的类似

（2）请求转发和重定向

请求转发forward 只有一次请求，而重定向是两次请求

请求转发

request.setAttribute(“forward_name”, “abcde”);//向request设置设置值

System.out.println(“请求转发获取的属性:” + request.getAttribute(“forward_name”));

request.getRequestDispatcher(“/” + path);

在另外一个Servlet当中可以得到值

重定向

request.setAttribute(“forward_name”, “abcde”);//向request设置设置值

System.out.println(“重定向获取的属性:” + request.getAttribute(“send_name”));

response.sendRedirect(path);

在另外一个Servlet当中不可以得到值。

2、http的长连接和短连接区别？

HTTP协议有HTTP/1.0版本和HTTP/1.1版本。

HTTP1.1默认保持长连接（HTTP persistent connection，也翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。

在 HTTP/1.0 中，默认使用的是短连接。

也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。从HTTP/1.1起，默认使用的是长连接，用以保持连接特性。

3、http常见的状态码有哪些？

● 200 OK 客户端请求成功

● 301Moved Permanently（永久移除)，请求的URL已移走。Response中应该包含一个 Location URL，说明资源现在所处的位置

● 302found 重定向

● 400Bad Request 客户端请求有语法错误，不能被服务器所理解

● 401Unauthorized 请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用

● 403 Forbidden 服务器收到请求，但是拒绝提供服务

● 404 Not Found 请求资源不存在，eg：输入了错误的URL

● 500 Internal Server Error 服务器发生不可预期的错误

● 503 Server Unavailable 服务器当前不能处理客户端的请求，一段时间后可能恢复正常

4、GET和POST的区别？

● GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，参数之间以&相连，如：login.action?name=zhagnsan&password=123456。

POST 把提交的数据则放置在是HTTP包的包体中。

● GET方式提交的数据最多只能是1024字节，理论上POST没有限制，可传较大量的数据。其实这样说是错误的，不准确的：“GET方式提交的数据最多只能是1024字节"，因为 GET 是通过URL提交数据，那么GET可提交的数据量就跟URL的长度有直接关系了。

而实际上，URL不存在参数上限的问题，HTTP协议规范没有对URL长度进行限制。

这个限制是特定的浏览器及服务器对它的限制。

IE对URL长度的限制是2083字节(2K+35)。

对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。

● POST的安全性要比GET的安全性高。

注意：这里所说的安全性和上面 GET 提到的“安全”不是同个概念。

上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的 Security的含义，

比如：通过GET 提交数据，用户名和密码将明文出现在URL上，因为登录页面有可能被浏览器缓存，其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用 GET 提交数据还可能会造成Cross-site request forgery攻击。

● Get 是向服务器发索取数据的一种请求，而Post是向服务器提交数据的一种请求，在FORM（表单）中，Method默认为"GET"，实质上GET和POST只是发送机制不同，并不是一个取一个发。

5、http中重定向和请求转发的区别？

本质区别：转发是服务器行为，重定向是客户端行为。

重定向特点：两次请求，浏览器地址发生变化，可以访问自己web之外的资源，传输的数据会丢失。

请求转发特点：一次强求，浏览器地址不变，访问的是自己本身的web资源，传输的数据不会丢失。

6、Cookie 和 Session 的区别？

Cookie是web服务器发送给浏览器的一块信息，浏览器会在本地一个文件中给每个web服务器存储Cookie。

以后浏览器再给特定的web服务器发送请求时，同时会发送所有为该服务器存储的Cookie。

Session是存储在web服务器端的一块信息。

Session对象存储特定用户会话所需的属性及配置信息。

当用户在应用程序的Web页之间跳转时，存储在Session对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。

7、Cookie和 Session的不同点：

无论客户端做怎样的设置，Session都能够正常工作。

当客户端禁用Cookie时将无法使用Cookie。

在存储的数据量方面：Session能够存储任意的java对象，Cookie只能存储String类型的对象。

8、session共享怎么做的（分布式如何实现session共享）？

问题描述：一个用户在登录成功以后会把用户信息存储在session当中，

这时session所在服务器为server1，那么用户在session失效之前如果再次使用app，

那么可能会被路由到 server2，这时问题来了，server2没有该用户的session，

所以需要用户重新登录，这时的用户体验会非常不好，

所以我们想如何实现多台server之间共享session，让用户状态得以保存。

● 服务器实现的session复制或session共享，这类型的共享session是和服务器紧密相关的，

比如webSphere或JBOSS在搭建集群时候可以配置实现session复制或session共享，但是这种方式有一个致命的缺点，

就是不好扩展和移植，比如我们更换服务器，那么就要修改服务器配置。

● 利用成熟的技术session复制，比如12306使用的gemfire，

比如常见的内存数据库如redis 或memorycache，这类方案虽然比较普适，

但是严重依赖于第三方，这样当第三方服务器出现问题的时候，那么将是应用的灾难。

● 将session维护在客户端，很容易想到就是利用cookie，但是客户端存在风险，数据不安全，而且可以存放的数据量比较小，

所以将session维护在客户端还要对session中的信息加密。我们实现的方案可以说是第二种方案和第三种方案的合体，

可以利用gemfire实现session复制共享，还可以session维护在redis中实现session共享，

同时可以将session维护在客户端的cookie中，但是前提是数据要加密。

这三种方式可以迅速切换，而不影响应用正常执行。

我们在实践中，首选gemfire或者redis作为session共享的载体，一旦session不稳定出现问题的时候，可以紧急切换cookie维护session作为备用，不影响应用提供服务。

这里主要讲解redis和cookie方案，gemfire比较复杂大家可以自行查看gemfire工作原理。利用redis做session共享，首先需要与业务逻辑代码解耦，不然session共享将没有意义，其次支持动态切换到客户端cookie模式。

redis的方案是，重写服务器中的HttpSession和HttpServletRequest，首先实现HttpSession接口，重写session的所有方法，将session以hash值的方式存在redis中，一个session的key就是sessionID，setAtrribute重写之后就是更新redis中的数据，getAttribute重写之后就是获取redis中的数据，等等需要将HttpSession的接口一一实现。

实现了HttpSesson，那么我们先将该session类叫做MySession（当然实践中不是这么命名的），当MySession出现之后问题才开始，怎么能在不影响业务逻辑代码的情况下，还能让原本的request.getSession()获取到的是MySession，而不是服务器原生的session。

这里，我决定重写服务器的HttpServletRequet，这里先称为MyRequest，

但是这可不是单纯的重写，我需要在原生的request基础上重写，

于是我决定在filter中，实现request的偷梁换柱，我的思路是这样的，MyRequest的构建器，必须以request作为参数，

于是我在filter中将服务器原生的request（也有可能是框架封装过的request），

当做参数new出来一个MyRequest，并且MyRequest也实现了HttpServletRequest接口，

其实就是对原生request的一个增强，这里主要重写了几个request的方法，

但是最重要的是重写了request.getSession()，

写到这里大家应该都明白为什么重写这个方法了吧，

当然是为了获取MySession，于是这样就在filter中，

偷偷的将原生的request换成MyRequest了，

然后再将替换过的request传入chan.doFilter()，

这样filter时候的代码都使用的是MyRequest了，