javaWeb项目之JSP学习笔记----2,JSP基本原理

最新推荐文章于 2023-07-15 11:22:28 发布

转载最新推荐文章于 2023-07-15 11:22:28 发布 · 163 阅读

文章标签：

#jsp

java 同时被 3 个专栏收录

40 篇文章

订阅专栏

ssm

33 篇文章

订阅专栏

阅读笔记

19 篇文章

订阅专栏

本文深入解析JSP的基本原理，包括JSP如何在服务器端运行、编译为Servlet的过程，以及每次访问JSP页面时的性能表现。此外，还探讨了JSP与Servlet的区别，以及如何在开发中有效利用两者特性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

JSP 基本原理

1.jsp文件必需在jsp服务器内运行。

2.jsp文件必须生成servlet才能执行。

3.每个jsp页面的第一个访问者速度很慢，因为必须等待jsp编译成servlet。

4.jsp页面的访问者无需安装任何客户端，甚至不需要可以运行的Java的运行环境，因为jsp页面输送到客户端的是标准的HTML页面。

　　在MyEclipse中创建一个【JSPLearning】的web项目，在【WebRoot】下创建一个“1.jsp”

　　可以看到头部分内容是比较多的，这原因其实和Servlet一样，都是由于MyEclipse创建JSP也是依靠模板来创建的（当然我们可以改模板代码使我们的JSP更加简洁）：

我们在<body>标签中输入如下代码：

复制代码

1  <body>
2          <%
3              Date date = new Date();
4              out.write(date.toLocaleString());
5           %>
6   </body>

复制代码

然后通过浏览器来浏览我们这个JSP，就可以看到当前时间：

　　写JSP的一大便捷之处在于如果该JSP不在【WEB-INF】文件下，那么每次修改代码只需保存即可在浏览器上观察，不需要像Servlet一样要重新部署。

我们看到上面JSP例子，不仅包含了HTML标签语言，同时融入了JAVA代码。

　　我们知道浏览器在访问JSP时能将JSP解释并将内容显示在浏览器上，JSP中有HTML的部分不用说，这浏览器肯定知道，但是我们上面的例子中JSP内还有Java部分，那么浏览器又不是JVM，怎么能执行这部分代码呢？

　　这就要说明一点了，其实浏览器访问JSP只是一个假象，真正的还是去访问Servlet。只是Servlet将JSP文件进行了翻译转换，即将JSP又变成了Servlet，然后输出给浏览器的就是这翻译转换后的Servlet。

　　那翻译转换后的Servlet在哪里呢？我们并没有看到在自己的web工程中有多出来的Servlet。其实这个Servlet就在Tomcat的【work】目录下。【work】目录是Tomcat的工作目录，也是Tomcat将JSP转换为class文件的工作目录。转换的工作原理是当浏览器访问某个JSP页面时，Tomcat会在【work】目录下把这个JSP页面转换成 .java文件（例如index.jsp会被转换成index_jsp.java，如果以数字开头，最前面还会有一下划线，例如: _1_jsp.java），而后编译为 .class文件，最后Tomcat容器通过ClassLoader类将这个转换后的 .class类装载进内存，响应客户端的工作。

　　当第一次有人来访问时，Tomcat需要将JSP转换成Servlet，访问可能会比较慢，但是一旦编译成Servlet后，除非JSP再次修改，否则之后再有用户访问就可以直接访问该Servlet，所以之后访问速度快。如果清空了【work】目录中的内容，那么所有的过程都会重新来过。

　　Tomcat会定时扫描容器内的JSP文件，当发现某个JSP进行了修改之后，Tomcat会重新编译转换这个JSP成Servlet。但是Tomcat对JSP的扫描是定时的，即不是实时的，所有并不是修改完后就立即生效（如上面所说的虽然修改JSP并不需要重新部署，但是有可能会发生访问时还未修改）。所以有时候为了能立刻生效，很多老前辈会建议在修改JSP后立即清除【work】目录里的内容。

　　（另外，Tomcat容器中，对于转换后的Java文件（例如index_jsp.java）的编译最大只支持64K，所以在其他服务器容器中的JSP移植到Tomcat容器中时会发生大JSP文件无法编译的情况。所以建议把JSP中的业务逻辑写入单独的类，在JSP中通过调用这个类的静态方法来执行，并将JSP中的JS，CSS等放入单独的JS文件或CSS文件依靠链接来加入样式等。）

　　上面说了这么多，我们来探究下Tomcat的【work】目录，我们会发现在这个目录下还有【Catalina】文件夹，还有【localhost】文件夹（如果我们有其他虚拟主机，那么也在【Catalina】下建立其他虚拟主机的目录来存放JSP转换后的class文件）：

这时候我们也看到了刚才刚建的web工程，接着我们继续点击进去（你会发现目录相当的多 T_T）:

进到【JSP】目录下，我们就可以看到刚才从1.JSP转换过来的 _1_jsp.java文件和 _1_jsp.class文件了（数字开头，所以前面有一个下划线）。

　　我们点击 _1_jsp.java文件，看一看里面的内容：

我们的 _1_jsp作为我们1.JSP所定义的类，继承了一个名为HttpJspBase这个类，而HttpJspBase类是可以从Tomcat的源码中（因为包中有apache）根据这个类的包名找到：

在这个类中继承了HttpServlet！所以这必须是一个Servlet ：

　　所以我们访问JSP，其实并不是真正在访问JSP，而是访问将JSP转换后的Servlet。在这个Servlet中，我们使用请求对象，将所需要的数据通过流的形式写回客户端，这点跟之前Servlet的学习到的是一样的。我们可以再看看那个浏览器访问的JSP页面，查看其码源：

　　我们看到其码源已经像是正常的HTML页面，因为只有这样浏览器才能解释和显示，同时在原来JSP写Java代码的地方直接变成了我们Java运行后的结果，这是为什么呢？

　　当知道JSP要转成Servlet，然后又Servlet来处理浏览器的请求，那根据之前学习的Servlet可以知道，这个请求是在Servlet中的service()方法中执行的，我们来看一看 _1_jsp 中的service()方法：

　　我们可以看到，在这个service方法中，确实有接收请求对象和响应对象为参数，同时在方法的内部，通过IO流对象将一些HTML代码通过write()方法写出到浏览器，并且也将在JSP中写的Java代码原封不动的搬移到这个Servlet中，这就是为什么可以在JSP中写Java代码，因为最后Java代码都会交给Servlet，剩下的就跟之前Servlet的学习没啥区别了，通过流写给响应对象，再将响应对象交给浏览器显示。

　　这里你可能会注意到我们在JSP编写是对Date对象是通过传统Java创建对象的方式来实现实例对象，而后面我们直接通过“out”这个对象来调用方法，那么这个“out”指的是哪个对象？还有别的什么对象可以直接调用吗？

　　我们已经知道了JSP最终是要转换为Servlet的，而Servlet就是一个Java代码的类，那么在JSP中写的Java代码会原封不动的搬移到Servlet上，那么某些某名出现在JSP上的对象肯定就是在Servlet上已经被定义过的，我们再次看看上面刚才的截图，可以看到“out”这个对象是JSPWriter的实例（截图中out还未获得引用，但是后面的代码会使out对象获得引用，具体请看JSP转换后的JAVA源码），通过JSP的API手册：

　　JspWriter是继承Writer的一个类。如果还记得通过响应对象Response.getWriter()方法获得的PrintWriter其实也是Writer下的一个类，所以JSP使用的字符流和Servlet能获取到的字符流其实都一个意思。

　　综上，正是因为在转换的Servlet中会自动帮我们定义了JspWriter类的一个实例对象：out，所以我们能在JSP中直接使用这个对象，当然通过上诉截图我们还可以直接使用别的已经定义好的对象，比在JSP中使用“application”代表这个web的Context对象，用“page”代表了JSP对于的这个Servlet，用“session”代表这个web应用中的Session对象等等，所以这些都是可以直接在JSP中使用，并代表某个类的对象的：