这是学习Java的基础，掌握程度的深浅甚至直接影响后面的整个学习进程。Java的核心主要包括几个部分：
1、初级的有语法基础、面向对象思想。
学习任何一门语言语法都是必须的，因为Java的接近自然语言，也是一种相对比较容易学的语言。同时面向对象编程更是其核心思想，要理解其实只要记住一句话就行了，那就是：一切皆是对象。
2、中级的IO流、多线程、反射及注解等。
IO流程、多线程等是相对比较高级一点的了，通过学习我们会发现这些都很有用而且很有趣。例如我们可以读取一个Excel文件、将一个文件分离，做一个时钟、使用多个线程发送邮件等等很多有意思的事。另外反射及注解更是后面流行框架SSH等的基础，在使用中你便会慢慢感受到它的无穷魅力。
3、高级一点的就是设计模式和框架之类了。
要学习好一门语言，仅仅会使用还是不够的，我们不仅要深入研究其原理，而且还要找到其一些共性的东西，从而减少反复的劳动，让代码可重用、更可靠且更容易被别人理解。
二、前端Web
现在来说Java最流行的应用还是Web开发。那么作为Web开发，对于前台的知识的学习也是必须的，当然并不是一定要按照前端工程师的标准去要求。但是一些基础的知识也是必须要掌握的，毕竟Web应用是前台和后台的一个交互的过程。像HTML、CSS、Javascript等都是基础的知识，另外作为开发人员对目前最流行的Javascript框架Jquery更是必学不可的。
三、数据库
有人说，所有的应用无非就是数据的输入、处理到输出的过程。期间同时可能还会涉及到数据的存储问题。对于结构化的数据，我们常用的还是像Oracle、Mysql和PostgreSQL之类的关系型数据库。同时针对数据库编程还是PL/SQL需要学习。使用Java访问数据库的话还有JDBC。那么对于非结构化的数据以及大数据该如何处理呢？其实这里也已经有了非常成熟的解决方案了，那便是Hadoop。就Hadoop而言他并不是一种思想，更多是一个实现了Mapreduce模式的框架。
四、J2EE
好了，前面这么多准备的工作。下面我们进入正题。作为Java开发，CoreJava是核心，而作为JavaWeb开发，我认为Servlet才是核心。Servlet是服务器端的Java应用程序，但是与普通的Java应用程序不同的是，它是由web服务器来加载启动，即我们常说的Servlet，如Tomcat便是servlet容器。另外谈到J2EE开发，这里有一个重要的模型不得不提一下，很多人其实已经想到了，那便是MVC（模型-视图-控制器）模型。在传统的web开发中，往往是JavaBean充当模型、JSP做视图而Servlet作为控制器。
五、框架
说到框架，其实已经提到了著名的MVC模型，SSH（Struts+Spring+Hibernate）就是一个非常好的实现。对于每一个框架的作用，我想就不用多说了，毕竟这里并不是想写一本教程。另外还有工作流开发的JBPM，搜索引擎Lucence及使系统对外提供接口的webservice应用组件等都是应该要掌握的。
六、服务器
关于服务器，像tomcat、jboss、weblogic及websphere等便不提了，因为太普遍了。这里要说的是Nginx，
Nginx ("engine x") 是一个高性能的 >
本文主要包括tomcat服务器的目录结构、工作模式、整体架构、I/O模型以及NIO、NIO2、APR三者的对比介绍。
我们先来看一下tomcat85和tomcat9中的home目录中的文件：
可以看到除掉一些说明文件之后，还有7个目录：
实际上除了主目录里有lib目录，在webapps目录下的web应用中的WEB-INF目录下也存在一个lib目录：
两者的区别在于：
● Tomcat主目录下的lib目录：存放的JAR文件 不仅能被Tomcat访问，还能被所有在Tomcat中发布的Java Web应用访问
● webapps目录下的Java Web应用的lib目录：存放的JAR文件 只能被当前Java Web应用访问
既然有多个lib目录，那么肯定就有使用的优先顺序，Tomcat类加载器的目录加载优先顺序如下：
Tomcat的类加载器负责为Tomcat本身以及Java Web应用加载相关的类。假如Tomcat的类加载器要为一个Java Web应用加载一个类，类加载器会按照以下优先顺序到各个目录中去查找该类的class文件，直到找到为止，如果所有目录中都不存在该类的class文件，则会抛出异常：
Tomcat不仅可以单独运行，还可以与其他的Web服务器集成，作为其他Web服务器的进程内或进程外的servlet容器。集成的意义在于：对于不支持运行Java Servlet的其他Web服务器，可通过集成Tomcat来提供运行Servlet的功能。
Tomcat有三种工作模式：
我们先从tomcat的源码目录来分析一下tomcat的整体架构，前面我们配置jsvc运行tomcat的时候，我们知道tomcat中启动运行的最主要的类是 orgapachecatalinastartupBootstrap ，那么我们在tomcat的源码中的java目录下的org目录的apache目录可以找到主要的源码的相对应的类。
图中的目录如果画成架构图，可以这样表示：
Tomcat 本质上就是一款Servlet 容器，因此 catalina 才是Tomcat的核心 ，其他模块都是为 catalina 提供支撑的。
单线程阻塞I/O模型是最简单的一种服务器I/O模型，单线程即同时只能处理一个客户端的请求，阻塞即该线程会一直等待，直到处理完成为止。对于多个客户端访问，必须要等到前一个客户端访问结束才能进行下一个访问的处理，请求一个一个排队，只提供一问一答服务。
如上图所示：这是一个同步阻塞服务器响应客户端访问的时间节点图。
这种模型的特点在于单线程和阻塞I/O。 单线程即服务器端只有一个线程处理客户端的所有请求，客户端连接与服务器端的处理线程比是 n:1 ，它无法同时处理多个连接，只能串行处理连接。而阻塞I/O是指服务器在读写数据时是阻塞的，读取客户端数据时要等待客户端发送数据并且把 *** 作系统内核复制到用户进程中，这时才解除阻塞状态。写数据回客户端时要等待用户进程将数据写入内核并发送到客户端后才解除阻塞状态。 这种阻塞带来了一个问题，服务器必须要等到客户端成功接收才能继续往下处理另外一个客户端的请求，在此期间线程将无法响应任何客户端请求。
该模型的特点：它是最简单的服务器模型，整个运行过程都只有一个线程，只能支持同时处理一个客户端的请求(如果有多个客户端访问，就必须排队等待)， 服务器系统资源消耗较小，但并发能力低，容错能力差。
多线程阻塞I/O模型在单线程阻塞I/O模型的基础上对其进行改进，加入多线程，提高并发能力，使其能够同时对多个客户端进行响应，多线程的核心就是利用多线程机制为每个客户端分配一个线程。
如上图所示，服务器端开始监听客户端的访问，假如有两个客户端同时发送请求过来，服务器端在接收到客户端请求后分别创建两个线程对它们进行处理，每条线程负责一个客户端连接，直到响应完成。 期间两个线程并发地为各自对应的客户端处理请求 ，包括读取客户端数据、处理客户端数据、写数据回客户端等 *** 作。
这种模型的I/O *** 作也是阻塞的 ，因为每个线程执行到读取或写入 *** 作时都将进入阻塞状态，直到读取到客户端的数据或数据成功写入客户端后才解除阻塞状态。尽管I/O *** 作阻塞，但这种模式比单线程处理的性能明显高了，它不用等到第一个请求处理完才处理第二个，而是并发地处理客户端请求，客户端连接与服务器端处理线程的比例是 1:1 。
多线程阻塞I/O模型的特点：支持对多个客户端并发响应，处理能力得到大幅提高，有较大的并发量，但服务器系统资源消耗量较大，而且如果线程数过多，多线程之间会产生较大的线程切换成本，同时拥有较复杂的结构。
在探讨单线程非阻塞I/O模型前必须要先了解非阻塞情况下套接字事件的检测机制，因为对于单线程非阻塞模型最重要的事情是检测哪些连接有感兴趣的事件发生。一般会有如下三种检测方式。
当多个客户端向服务器请求时，服务器端会保存一个套接字连接列表中，应用层线程对套接字列表轮询尝试读取或写入。如果成功则进行处理，如果失败则下次继续。这样不管有多少个套接字连接，它们都可以被一个线程管理，这很好地利用了阻塞的时间，处理能力得到提升。
但这种模型需要在应用程序中遍历所有的套接字列表，同时需要处理数据的拼接，连接空闲时可能也会占用较多CPU资源，不适合实际使用。
这种方式将套接字的遍历工作交给了 *** 作系统内核，把对套接字遍历的结果组织成一系列的事件列表并返回应用层处理。对于应用层，它们需要处理的对象就是这些事件，这是一种事件驱动的非阻塞方式。
服务器端有多个客户端连接，应用层向内核请求读写事件列表。内核遍历所有套接字并生成对应的可读列表readList和可写列表writeList。readList和writeList则标明了每个套接字是否可读/可写。应用层遍历读写事件列表readList和writeList，做相应的读写 *** 作。
内核遍历套接字时已经不用在应用层对所有套接字进行遍历，将遍历工作下移到内核层，这种方式有助于提高检测效率。 然而，它需要将所有连接的可读事件列表和可写事件列表传到应用层，假如套接字连接数量变大，列表从内核复制到应用层也是不小的开销。 另外，当活跃连接较少时， 内核与应用层之间存在很多无效的数据副本 ，因为它将活跃和不活跃的连接状态都复制到应用层中。
通过遍历的方式检测套接字是否可读可写是一种效率比较低的方式，不管是在应用层中遍历还是在内核中遍历。所以需要另外一种机制来优化遍历的方式，那就是 回调函数 。内核中的套接字都对应一个回调函数，当客户端往套接字发送数据时，内核从网卡接收数据后就会调用回调函数，在回调函数中维护事件列表，应用层获取此事件列表即可得到所有感兴趣的事件。
内核基于回调的事件检测方式有两种
第一种是用 可读列表readList 和 可写列表writeList 标记读写事件， 套接字的数量与 readList 和 writeList 两个列表的长度一样 。
上面两种方式由 *** 作系统内核维护客户端的所有连接并通过回调函数不断更新事件列表，而应用层线程只要遍历这些事件列表即可知道可读取或可写入的连接，进而对这些连接进行读写 *** 作，极大提高了检测效率，自然处理能力也更强。
单线程非阻塞I/O模型最重要的一个特点是，在调用读取或写入接口后立即返回，而不会进入阻塞状态。虽然只有一个线程，但是它通过把非阻塞读写 *** 作与上面几种检测机制配合就可以实现对多个连接的及时处理，而不会因为某个连接的阻塞 *** 作导致其他连接无法处理。在客户端连接大多数都保持活跃的情况下，这个线程会一直循环处理这些连接，它很好地利用了阻塞的时间，大大提高了这个线程的执行效率。
单线程非阻塞I/O模型的主要优势体现在对多个连接的管理，一般在同时需要处理多个连接的发场景中会使用非阻塞NIO模式，此模型下只通过一个线程去维护和处理连接，这样大大提高了机器的效率。一般服务器端才会使用NIO模式，而对于客户端，出于方便及习惯，可使用阻塞模式的套接字进行通信。
在多核的机器上可以通过多线程继续提高机器效率。最朴实、最自然的做法就是将客户端连接按组分配给若干线程，每个线程负责处理对应组内的连接。比如有4个客户端访问服务器，服务器将套接字1和套接字2交由线程1管理，而线程2则管理套接字3和套接字4，通过事件检测及非阻塞读写就可以让每个线程都能高效处理。
多线程非阻塞I/O模式让服务器端处理能力得到很大提高，它充分利用机器的CPU，适合用于处理高并发的场景，但它也让程序更复杂，更容易出现问题（死锁、数据不一致等经典并发问题）。
最经典的多线程非阻塞I/O模型方式是Reactor模式。首先看单线程下的Reactor，Reactor将服务器端的整个处理过程分成若干个事件，例如分为接收事件、读事件、写事件、执行事件等。Reactor通过事件检测机制将这些事件分发给不同处理器去处理。在整个过程中只要有待处理的事件存在，即可以让Reactor线程不断往下执行，而不会阻塞在某处，所以处理效率很高。
基于单线程Reactor模型，根据实际使用场景，把它改进成多线程模式。常见的有两种方式：一种是在耗时的process处理器中引入多线程，如使用线程池；另一种是直接使用多个Reactor实例，每个Reactor实例对应一个线程。
Reactor模式的一种改进方式如下图所示。其整体结构基本上与单线程的Reactor类似，只是引入了一个线程池。由于对连接的接收、对数据的读取和对数据的写入等 *** 作基本上都耗时较少，因此把它们都放到Reactor线程中处理。然而，对于逻辑处理可能比较耗时的工作，可以在process处理器中引入线程池，process处理器自己不执行任务，而是交给线程池，从而在Reactor线程中避免了耗时的 *** 作。将耗时的 *** 作转移到线程池中后，尽管Reactor只有一个线程，它也能保证Reactor的高效。
Reactor模式的另一种改进方式如下图所示。其中有多个Reactor实例，每个Reactor实例对应一个线程。因为接收事件是相对于服务器端而言的，所以客户端的连接接收工作统一由一个accept处理器负责，accept处理器会将接收的客户端连接均匀分配给所有Reactor实例，每个Reactor实例负责处理分配到该Reactor上的客户端连接，包括连接的读数据、写数据和逻辑处理。这就是多Reactor实例的原理。
Tomcat支持的I/O模型如下表（自85/90 版本起，Tomcat移除了对BIO的支持），在 80 之前 ， Tomcat 默认采用的I/O方式为 BIO ， 之后改为 NIO。 无论 NIO、NIO2 还是 APR， 在性能方面均优于以往的BIO。
Tomcat中的NIO模型是使用的JAVA的NIO类库，其内部的IO实现是同步的（也就是在用户态和内核态之间的数据交换上是同步机制），采用基于selector实现的异步事件驱动机制（这里的异步指的是selector这个实现模型是使用的异步机制）。 而对于Java来说，非阻塞I/O的实现完全是基于 *** 作系统内核的非阻塞I/O，它将 *** 作系统的非阻塞I/O的差异屏蔽并提供统一的API，让我们不必关心 *** 作系统。JDK会帮我们选择非阻塞I/O的实现方式。
NIO2和前者相比的最大不同就在于引入了异步通道来实现异步IO *** 作，因此也叫AIO（Asynchronous I/O）。NIO2 的异步通道 APIs 提供方便的、平台独立的执行异步 *** 作的标准方法。这使得应用程序开发人员能够以更清晰的方式来编写程序，而不必定义自己的 Java 线程，此外，还可通过使用底层 OS 所支持的异步功能来提高性能。如同其他 Java API 一样，API 可利用的 OS 自有异步功能的数量取决于其对该平台的支持程度。
异步通道提供支持连接、读取、以及写入之类非锁定 *** 作的连接，并提供对已启动 *** 作的控制机制。Java 7 中用于 Java Platform（NIO2）的 More New I/O APIs，通过在 javaniochannels 包中增加四个异步通道类，从而增强了 Java 14 中的 New I/O APIs（NIO），这些类在风格上与 NIO 通道 API 很相似。他们共享相同的方法与参数结构体，并且大多数对于 NIO 通道类可用的参数，对于新的异步版本仍然可用。主要区别在于新通道可使一些 *** 作异步执行。
异步通道 API 提供两种对已启动异步 *** 作的监测与控制机制。第一种是通过返回一个 javautilconcurrentFuture 对象来实现，它将会建模一个挂起 *** 作，并可用于查询其状态以及获取结果。第二种是通过传递给 *** 作一个新类的对象， javaniochannelsCompletionHandler ，来完成，它会定义在 *** 作完毕后所执行的处理程序方法。每个异步通道类为每个 *** 作定义 API 副本，这样可采用任一机制。
Apache可移植运行时（Apache Portable Runtime，APR） 是Apache >Servlet如何处理多个请求访问？\x0d\Servlet容器默认是采用单实例多线程的方式处理多个请求的：\x0d\1当web服务器启动的时候（或客户端发送请求到服务器时），Servlet就被加载并实例化(只存在一个Servlet实例)；\x0d\2容器初始化化Servlet主要就是读取配置文件（例如tomcat,可以通过servletxml的设置线程池中线程数目，初始化线程池通过webxml,初始化每个参数值等等。\x0d\3当请求到达时，Servlet容器通过调度线程(Dispatchaer Thread) 调度它管理下线程池中等待执行的线程（Worker Thread）给请求者；\x0d\4线程执行Servlet的service方法；\x0d\5请求结束，放回线程池，等待被调用；\x0d\（注意：避免使用实例变量（成员变量），因为如果存在成员变量，可能发生多线程同时访问该资源时，都来 *** 作它，照成数据的不一致，因此产生线程安全问题）\x0d\\x0d\从上面可以看出：\x0d\第一：Servlet单实例，减少了产生servlet的开销；\x0d\第二：通过线程池来响应多个请求，提高了请求的响应时间；\x0d\第三：Servlet容器并不关心到达的Servlet请求访问的是否是同一个Servlet还是另一个Servlet，直接分配给它一个新的线程；如果是同一个Servlet的多个请求，那么Servlet的service方法将在多线程中并发的执行；\x0d\第四：每一个请求由ServletRequest对象来接受请求，由ServletResponse对象来响应该请求。\x0d\Servlet容器如何同时来处理多个请求\x0d\Java的内存模型JMM（Java Memory Model） ，JMM主要是为了规定了线程和内存之间的一些关系。根据JMM的设计，系统存在一个主内存(Main Memory)，Java中所有实例变量都储存在主存中，对于所有线程都是共享的。每条线程都有自己的工作内存(Working Memory)，工作内存由缓存和堆栈两部分组成，缓存中保存的是主存中变量的拷贝，缓存可能并不总和主存同步，也就是缓存中变量的修改可能没有立刻写到主存中；堆栈中保存的是线程的局部变量，线程之间无法相互直接访问堆栈中的变量。\x0d\Servlet采用多线程来处理多个请求同时访问。servlet依赖于一个线程池来服务请求。线程池实际上是一系列的工作者线程集合。Servlet使用一个调度线程来管理工作者线程。 \x0d\当容器收到一个Servlet请求，调度线程从线程池中选出一个工作者线程,将请求传递给该工作者线程，然后由该线程来执行Servlet的service方法。当这个线程正在执行的时候,容器收到另外一个请求,调度线程同样从线程池中选出另一个工作者线程来服务新的请求,容器并不关心这个请求是否访问的是同一个Servlet当容器同时收到对同一个Servlet的多个请求的时候，那么这个Servlet的service()方法将在多线程中并发执行。 \x0d\Servlet容器默认采用单实例多线程的方式来处理请求，这样减少产生Servlet实例的开销，提升了对请求的响应时间，对于Tomcat可以在serverxml中通过元素设置线程池中线程的数目。 \x0d\注意：服务器可以使用多个实例来处理请求，代替单个实例的请求排队带来的效益问题。服务器创建一个Servlet类的多个Servlet实例组成的实例池，对于每个请求分配Servlet实例进行响应处理，之后放回到实例池中等待下此请求。这样就造成并发访问的问题。 \x0d\此时,局部变量(字段)也是安全的，但对于全局变量和共享数据是不安全的，需要进行同步处理。而对于这样多实例的情况SingleThreadModel接口并不能解决并发访问问题。 SingleThreadModel接口在servlet规范中已经被废弃了
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）