想做JAVAWEB后台的话，要学习哪些知识

首先要明确后端包括哪些职业：DBA（数据库维护优化专家），Developer（程序猿），Architect（构架师），Scrum master及类似（敏捷开发专家），Project Manager（产品狗），Maintenance&IT support（通讯和服务器相关），当然这只是一个大致的分类，并没有一个清晰的界限。

按程序猿内功而言：关系型数据库，领域驱动设计（Domain-Driven Design），设计模式Design Pattern，算法Algorithm，面向对象编程OOP（SOLID），线程安全，事件驱动，测试驱动开发，依赖注入框架，等等。

对于初学Java并且有志于后端开发的同学来说，需要重点关注以下几个部分：

基础：比如计算机系统、算法、编译原理等等

Web开发： 主要是Web开发相关的内容，包括HTML/CSS/js（前端页面）、 Servlet/JSP（J2EE）以及MySQL（数据库）相关的知识。它们的学习顺序应该是从前到后，因此最先学习的应该是HTML/CSS/JS（前端页面）。

J2EE：你需要学习的是Servlet/JSP（J2EE）部分，这部分是Java后端开发必须非常精通的部分，因此这部分是这三部分中最需要花精力的。关于Servlet/Jsp部分视频的选择，业界比较认可马士兵的视频。

最后一步，你需要学会使用数据库，mysql是个不错的入门选择，而且Java领域里主流的关系型数据库就是mysql。这部分一般在你学习Servlet/Jsp的时候，就会接触到的，其中的JDBC部分就是数据库相关的部分。你不仅要学会使用JDBC *** 作数据库，还要学会使用数据库客户端工具，比如navicat，sqlyog，二选一即可。

开发框架：目前比较主流的是SSM框架，即spring、springmvc、mybatis。你需要学会这三个框架的搭建，并用它们做出一个简单的增删改查的Web项目。你可以不理解那些配置都是什么含义，以及为什么要这么做，这些留着后面你去了解。但你一定要可以快速的利用它们三个搭建出一个Web框架，你可以记录下你第一次搭建的过程，相信我，你一定会用到的。还要提一句的是，你在搭建SSM的过程中，可能会经常接触到一个叫maven的工具。这个工具也是你以后工作当中几乎是必须要使用的工具，所以你在搭建SSM的过程中，也可以顺便了解一下maven的知识。在你目前这个阶段，你只需要在网络上了解一下maven基本的使用方法即可，一些高端的用法随着你工作经验的增加，会逐渐接触到的。

因此，你需要去看一些JDK中的类的源码，也包括你所使用的框架的源码。这些源码能看懂的前提是，你必须对设计模式非常了解。否则的话，你看源码的过程中，永远会有这样那样的疑问，这段代码为什么要这么写？为什么要定义这个接口，它看起来好像很多余？由此也可以看出，这些学习的过程是环环相扣的，如果你任何一个阶段拉下来了，那么你就真的跟不上了，或者说是一步慢步步慢。而且我很负责的告诉你，我在这个阶段的时候，所学习的东西远多于这里所罗列出来的。

总而言之，这个阶段，你需要做的是深入了解Java底层和Java类库（比如并发那本书就是Java并发包javaconcurrent的内容），也就是JVM和JDK的相关内容。而且还要更深入的去了解你所使用的框架，方式比较推荐看源码或者看官方文档。

a）>

此连接器支持>

拥有这个连接器，Tomcat才能成为一个Web服务器，但还额外可处理 servlet 和 jsp

每个监听器监听一个你电脑上的TCP端口（而没有UDP端口）

一个Service可以配置多个>

b）AJP Connector

AJP连接器可以通过AJP协议和一个Web容器进行交互

当你想让Apache 和 Tomcat结合并且你想让Apache处理静态页面的内容的时候用AJP，或者你想利用Apache的SSL处理能力时 《linux 就该这么学》

特殊于>

c）>类型转换错误，可能是有jar包存在版本冲突。相同的方法名，但是参数不同。本地class load的顺序和服务器上的加载顺序不同导致本地调用了正确的方法，但服务器上调用了错误的方法。建议检查报错的类方法，在项目中的jar中是否存在多个。

一 什么是架构 和架构相关的几个问题域架构需要解决的非业务问题域包括如下 A 系统目标 系统性能 稳定性 B 项目目标 开发成本 质量C 项目过程 需求的不确定性和开发过程的团队协作性不同的问题域 解决之道也不相同！而同一问题域的不同层次的要求 解决之道也不尽相同

什么是架构架构到底是啥 愚以为下面的这段英文描述的很清楚

That s like asking what is culture Culture is the way you do things in a group of people Architecture is the way you do things in a sofare product You could argue by ogy then that architecture is to a sofare product as culture is to a team It is how that team has established and chosen its conventions

Which leads us inevitably to the question of goodness How do you know if an architecture is good Consider an architecture that isn t built using a strong domain model and instead relies heavily on stored procedures That might be OK or it might not be OK You could have decided that part of your architecture is to use a really strong domain model and not use stored procedures right So an architecture is some reasonable regularity about the structure of the system the way the team goes about building its sofare and how the sofare responds and adapts to its own environment How well the architecture responds and adapts and how well it goes through that construction process is a measure of whether that architecture is any good

The system architecture determines how hard or easy it is to implement a given feature Good architectures are those in which it is considered easy to create the features desired In that the way to judge whether an architecture is good is whether the architecture is good for the purposes to which it is applied

The definition of goodness has to be related to fitness for purpose Is this glove good I don t know What are you doing with the glove Are you throwing snowballs cooking barbeques or playing golf There s a set of changes that are going to occur to a sofare system over time Probably the utilitarian or most useful definition of goodness is the answer to this question: are the changes that will keep this system successful in this domain in this product line relatively easy If they are then it s probably a good architecture

架构的背后为了实现架构的目标涉及到以下三个方面 技术 组织和过程 这里举例说明 ) 技术对开发效率和运行性能 以及组织和过程的影响 案例A．映射的问题 公司产品的一个重要需求是根据客户输入 映射到PDF文件上 技术上整体实现需要四个步骤 在PDF文件上画好所有的数据域 通过读入一个XML映射文件 获得运行数据并生成FDF 合并FDF和PDF生成目标文件 后两步工作都由代码自动化了 因而实现的主要工作在于前两步

在第一个实现版本里 XML映射文件的DTD太简单 致使一个xml文件至少在 行左右 同时xml文件太verbose了 这样的结果直接导致运行系统在峰值时 由于XML消耗了大量内存 G的内存根本吃不消 同时对XML解析执行使用了CPU的大量时间 导致开发人员需要做大量的工作 开发效率降低了 通常需要尽一周才能完成一个xml文件 员工都不愿意做 也导致开发过程的漫长 开发部门对于BA部门和ST部门的要求反应变的缓慢

在第二个版本的实现中 重新实现了DTD 加入了大量的关键字同时也消除了verbose 大量的缩小了XML大小 从 多行减低到 多行 不仅减低了内存使用 提高执行效率 也提高了开发效率 基本只要一天就可以完成一个映射文件 同时对BA部门和ST部门的反应也快了

案例B 脚本的问题 产品在web层提供了脚本支持 出于方便开发的目的 但是没有对脚本的环境限制 脚本可以做系统程序的大部分工作 导致开发人员偷懒 在web层混入了大量业务逻辑代码 最终造成业务逻辑分散而不可控制

) 组织结构对技术 开发效率和应变能力的影响 案例A 部门的分工问题 开发部门根据不同的职责 分成A B和C等数个小组 大部分开发中互不相干 但也有时候 需要跨组的支持 比如B要实现某个需求 需要A在一定条件在记录一个或多个信息 因为每个开发人员各自负责一部分工作 导致跨组沟通的困难 同时由于整个开发部采取任务绩效 有时间压力 加上只是一个小的要求 于是在A人员的同意下 B人员直接在A代码中写入业务逻辑 每次都是这样的小改动 不断的发展后 代码开发变凌乱

案例B 开发的历史问题 当某个开发人员写下的代码 有是问题的 接手开发人员由于文档不全以及没有测试用例 不愿意承担变化的代价 选择小修小补 这个小修小补有可能和有问题的代码混杂 导致更大的代码

) 过程对开发效率和应变能力 以及组织的影响案例A 过程的问题 开发部门的上下游部门BA部门和ST部门的合作关系 ST部门的绩效考核 考核基于发现错误的数量 导致ST为了完成任务 提出一些非正常性要求 PM部门出于部门的方便通常提出一些实现难度比较大要求 开发部门本身又存在时间压力 导致一些需求的实现本应在低一层的代码中实现的 却在高层用蹩足的方式实现

案例B 帮助系统的问题 帮助系统一开始采用一个个单独分散的静态页面 出于性能的考虑和部门负责考虑 帮助系统不断改进中 过程缺乏组织性 文件的命名规则随意 存储位置随意 造成了管理的混乱 直接的后果是页面的入口混乱和各自引用关系混乱 在帮助系统的第二版 从静态页面转成动态页面 采取统一分类和命名规则 并统一了入口 同时采取分级管理引用关系 适度冗余 虽然减低了运行性能 但提高了开发效率和可维护性

二 架构的性能问题解决讨论性能问题——嗯 一个非常神圣而高深的问题的 从我刚刚开始工作的时候 至今依然是 然而我相信 一定存在一个基本的思路和方法 我以为解决性能问题的工作还是在于分解 通过分解来确定问题域

先介绍三个公式性能问题的公式: 总处理单量 = 总处理时间/ 单笔请求处理时间 总并发数这个公式另一个写法为:总处理时间 = 单笔请求处理时间 总处理单量 / 总并发数不同的写法代表不同个关注点 适合不同类型的业务类型 一般说前一种写法代表在线请求的 后一种写法代表后台batch

也有客户给明确要求系统要支持xxx并发 这个就需要了解客户的这个并发数是如何计算得来 需要通过分析客户的业务 而通常是根据总处理单量来确定客户实际的并发数

但无论如如何 四个变量中 总处理单量和总处理时间是先被确定的 换句话说需要关注是单笔请求处理时间和并发数 也就是降低单笔请求处理时间或者增加并发数

对于单笔请求处理时间 其公式为 单笔请求处理时间 ＝ 数据计算时间 ＋ 数据读写时间＋其它技术导致时间消耗很显然降低单笔请求处理时间就需要降低三个因素消耗的时间 降低单笔请求处理时间第一原则是 只计算一次 缓存计算结果 降低数据读取时间 分三种 Global的 系统启动时加载 Long Time 可采用LRU方式cache Per operation 第一次访问加载 operation结束后丢弃 降低数据写入时间例如文件写入通过buffer一次flush 对于SQL采用batch提交（hibernate的做法）

改进计算时间 针对不同技术结构采用不同手段 让计算支持并发 提高性能 例如采用MapReduce的方式 改进算法 例如数据库中的SQL改进 减少不必要计算时间 减少其它技术原因导致的消耗如JVM的GC导致性能消耗等对于总并发数 其公式为 总并发数 ＝ 单机服务器并发能力 总并发服务器数那么如何确定那些因素需要调整呢 在于两个方面的分解

业务层面业务层面只是指通过业务行为分析 把性能问题分解为不同的部分 每个部分面临性能压力现状和目标 最终确定需要优化的问题域

业务层面分解包括 个内容: 功能 内容 时间和区域 最重要的是前三个 以ebay为例 ebay对于前端功能划分划分为 多个功能 不同的服务器处理不同的功能

内容是指内容热点 比如对于search来说 就按体育 数码 音乐等划分 不同内容有不同热点数据 以及不同搜索关键匹配 时间 时间是一个非常重要的因素 在一些特点是时间段呢 性能的要求会非常高 比如下半夜的访问点击量和白天的就有不同 对于一些batch来说 月末或者年末处理的单量就有明显的提高 比如分红险的记息 平时每天只有 单 而年末会有 w单

地点划分 不太常见 不过也有助于分配计算资源 业务层面的分析不仅是确定问题所在 还是确定优化的策略 比如有一个batch计算 执行时间比较长 而通过业务分析 发现该计算只针对特定的业务 系统全部有效单量是 w单 而符合计算要求的只有 单 只要加上一个前置判断就可以免除无谓的计算 运行时间减少数个小时(大约 秒一单)

技术层面系统建立时技术结构 通常一个系统结构如下:接入网络 Web服务器 应用服务器 以及数据库服务器 在这样结构下 要小心的分析和验证系统性能的瓶颈 需要优化Web服务器 或者提高数据库并发能力等等 这部分网上的资料非常多

三 架构的开发成本以及品质问题解决讨论架构一个重大关注点在于控制开发成本 这点很重要 因为通常讲维护成本是开发成本的 倍 降低开发成本核心 在于提高效率 这也意味着提高了开发对需求的响应时间 而时间对公司来说是重要的

提高开发效率和品质的基本手段是分解——即充分的分离系统中不同的关注点 好处不用说了 可以并发的工作 每个人面对的问题都简单而容易 *** 作 而与分解对应的集成 只有提供了好的集成能力 分解才成为现实 而只有分解了 才能清晰的提供业务更多适应性 分解和集成的手段分为编程语言和技术框架两个层面 所谓语言就是强框架 而框架就是弱语言

现代面向对象的语言提供如下能力 抽象和派生能力 以及接口隔离能力 实际提供两种分解和集成能力 把逻辑分解在两个层次中 而通过继承的方式把两个部分集成在一起 把逻辑的外观和实现分解在两个地方 而通过接口实现的方式把两部分集成在一起

另一种语言AspectJ或者C#语言 之后提供的特性 把流程逻辑 分解在不同的地方 而通过签名匹配 利用代码生成的方式来把几部分集成在一起

然而语言提供的集成能力 毕竟底层 而且有限 扩展起来也格外小心 因而技术框架提供另外的集成能力就格外重要 对象关联关系的分解和集成 如Spring提供容器管理能力 模块间关联关系的分解和集成 如OSGi ESB等 不同系统的类型分解和集成 如Spring利用动态代理提供的Exporter模式 流程逻辑的分解和集成 如Spring Web Flow以及jBPM 讨论完手段 现在要转身看看我们面临的问题域了 问题域可分解为两种类型 业务上和技术上 （又见分解 分而治之真是老祖宗传下的灵丹妙药啊）

业务上 问题域分解为 逻辑的纵向抽象层次 以及逻辑的横向模块分解和集成 技术上 问题域分解为 纵向的技术主题 以及横向的技术职责的分解和集成 所以通常而言 领域模型设计中 模块分解 抽象分层和职责分层都是重要手段 问题域为 流程 业务实体和计算（包括规则）

对象的抽象分解和集成 对象的依赖分解和集成（模块内和模块外） 流程的分解和集成（页面流 工作流以及计算流程） 进程边界 用户请求重定向 以及业务数据持久化等 B 通常语言做为架构的基础引入和更换是有巨大风险的 而通过提供强大的框架能力 框架尽可能多的完成技术问题 并通过元数据 模式以及约定降低业务和框架的耦合 避免因为框架升级带来不必要的成本

从技术手段上 提高开发效率的另外两个手段是代码生成和类库引用 但代码生成和类库引用 都只解决了逻辑的分解能力 没有提供集成能力 所以一般情况下需要提供框架集成 尤其代码生成需要在系统的最外层 避免集成带来的问题

lishixinzhi/Article/program/net/201311/15671

Java中的垃圾回收器几乎是面试中的必考点，无论是面试初级，中级还是高级，总免不了要问一问垃圾回收器的一些知识点。不管在实际开发中你使用程度怎么样，为了面试不被压价，还是非常有必要对它做一个较深入的理解。

本篇对JVM中常用的几种垃圾回收器的主要特点，使用场景及优化建议做一个简单介绍，希望起到抛砖引玉的效果，对你入门有所帮助。

新生代回收器

老年代回收器

新生代和老年代回收器

Serial收集器是最基本、发展 历史 最悠久的收集器。JDK131前是HotSpot新生代收集的唯一选择。

运行示意图

有如下特点：

简单高效，由于采用的是单线程的方法，因此与其他类型的收集器相比，对单个cpu来说没有了上下文之间的的切换，效率比较高。

会在用户不知道的情况下停止所有工作线程。

在用户的桌面应用场景中，可用内存一般不大，可以在较短时间内完成垃圾收集，只要不频繁发生，这是可以接受的

对于限定单个CPU的环境来说，Serial收集器没有线程切换开销，可以获得最高的单线程收集效率

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集之外，其余均和Serial 收集器一致。

运行示意图

多线程版本的Serial，可以更加有效地利用系统资源

同Serial，会在用户不知道的情况下停止所有工作线程

Server模式下使用，亮点是除Serial外，目前只有它能与CMS收集器配合工作，是一个非常重要的垃圾回收器。

运行示意图

有如下特点：

追求高吞吐量，高效利用CPU，使吞吐量优先，且能进行精确控制。

根据相关特性，我们很容易想到它的使用场景，即：当应用程序运行在具有多个CPU上，对暂停时间没有特别高的要求时，程序主要在后台进行计算，而不需要与用户进行太多交互等就特别适合ParNew收集器。

Serial Old是Serial收集器的老年代版本，同样是一个单线程收集器，使用标记-整理算法。

有如下特点：

优劣势基本和Serial无异，它是和Serial收集器配合使用的老年代收集器。

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。采用的算法是“标记-清除”，运作过程分为四个步骤：

运行示意图

有如下特点：

如常见WEB、B/S系统的服务器上的应用。

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法，可以充分利用多核CPU的计算能力。

有如下特点：

优劣势参考Parallel Scavenge收集器。

这样在注重吞吐量以及CPU资源敏感的场景，就有了Parallel Scavenge（新生代）加Parallel Old（老年代）收集器的"给力"应用组合；

G1（Garbage-First）是JDK7-u4才推出商用的收集器

有如下特点：

G1收集器是当今收集器技术发展的最前沿成果。

G1 需要记忆集 (具体来说是卡表)来记录新生代和老年代之间的引用关系，这种数据结构在 G1 中需要占用大量的内存，可能达到整个堆内存容量的 20% 甚至更多。而且 G1 中维护记忆集的成本较高，带来了更高的执行负载，影响效率。

按照《深入理解Java虚拟机》作者的说法，CMS 在小内存应用上的表现要优于 G1，而大内存应用上 G1 更有优势，大小内存的界限是6GB到8GB。

个人以为G1已经基本全面压制cms、parallel等回收器，缺点见上面的劣势。但如果不是追求极致的性能，基本可以无脑G1

基本就介绍这些了，垃圾回收器基本不变的知识点多，学会（理解）可以应付N年的相关知识的面试，又是高频面试考点，各位同学还是值得在这块下点功夫的。文中有任何不足，错误欢迎指出，共同进步！

---