本文是上一篇文章的后续文，具体请回顾上文
一、Ajax请求Session超时问题
我在做项目时有时会遇到session超时问题，如果session超时，平常请求没有什么问题，通过拦截器可以正确跳到登陆页面，可是你如果用ajax请求的话这就出现问题了，因为ajax是异步的，局部刷新，所以登陆界面不会再全页面中显示，他只会显示到页面的一部分当中。所以根据我这几年的经验找到了我认为比较好的一种方法。因为那我用的框架是和struts2集成的，所以就在拦截器中进行设置：
首先判断session是否为空就是判断session是否超时，如果超时就取出请求的head头信息request.getHeader("x-requested-with")，如果不为空就和XMLHttpRequest(Ajax标识)进行比较 (request.getHeader("x-requested-with").equalsIgnoreCase("XMLHttpRequest"))) 如果相等说明此请求是ajax请求。
如果是ajax请求就可以用response.setHeader("键","值")来设置一个标识来告诉用户这是ajax请求并且session超时时发出的，这样我就可以在回调函数中取出自己设置的那个唯一标识：XMLHttpRequest.getResponseHeader("");如果取出的值是和自己在后台中设置的值一样的话，就证明session已经超时，这样就可以设置window.location.replace("登陆界面")，来跳转到登陆界面了。
这样做虽然解决了问题，但是，会在每个回调函数中写入那些代码，这样的话代码就会显得特别零散，所以就想能不能定义一个全局的设置所以就找到了jqery的ajaxSetUp方法，通过ajaxSetUp对jqery的ajax进行全局的判断(ajaxSetUp就相当于ajax的拦截器)，通过设置ajaxSetUp里的complete，它就相当于回调函数，这样那就弥补了上一方法的不足。
我做项目时还用到$(document).ajaxStart()，这是ajax请求时的事件；$(document).ajaxSuccess()，这是AJAX请求成功后的事件。我一般用他们来显示遮罩层和隐藏遮罩层用的加遮罩层是为了不让用户重复提交，更提高了用户体验度，让用户知道已经提交了。
七：java线程池概述
java线程池的工作原理和数据库连接池的差不多，因为每次重新创建线程
都是很耗资源的操作，所以我们可以建立一个线程池，这样当需要用到线程
进行某些操作时，就可以直接去线程池里面找到空闲的线程，这样就可以直接
使用，而不用等到用到的时候再去创建，用完之后可以把该线程重新放入线程池
供其他请求使用从而提高应用程序的性能。
线程池的核心流程:
1.构建一个 ThreadPoolExecutor 并指定默认要创建的线程的数量
2.通过 threadPool.execute()
去添加一个个要执行的线程即实现了Runable接口的java类
3.在实现了Runable接口的java类的run方法中写入具体的业务代码
线程池的业务场景：
我在工作的时候，当时一个同事给我提了一个需求，目前有大量的图片
需要处理生产缩略图并进行加水印，因为按照普通的处理方法一个个的
进行处理太慢了，问我有没有好的解决方案，这个时候我就想到了java中
的线程池，我构建了一个线程数为5个线程池，然后采用分段批量提取的
方式每500条为一组数据进行图片信息的提取，然后再把这些通过Threadpool的
execute方法交给线程池中的线程进行处理，即充分使用了CPU硬件资源又加快
了大数据情况下程序的处理效率。
我当时在工作的过程中，认识一个做电商的朋友，他们当时公司才起步，很多
技术都不成熟，所以就常常和我探讨一些技术问题，有次他向我请教一个问题，
问我如何才能提高网站的性能，我根据自己在项目中的经验以及自己以前阅读的
关于优化方面的资料给他提出了很多建议，如用lucene进行全文检索，用memcached
进行分布式缓存，以及通过spring定时器结合freeMarker模板引擎来生成静态
页面，由于要生成的页面的数量比较多，考虑到程序的性能，我建议他结合
java的线程池进行工作，这样就可以充分使用了CPU硬件资源又加快
了大数据情况下程序的处理效率。
八、OSCache概述
oscache是一个高性能的j2ee框架，可以和任何java代码进行集成，并且还可以通过标签对页面内容进行缓存，还以缓存请求。
我们通常将那些频繁访问但是又不是经常改变的数据进行缓存。为了保证缓存数据的有效性，在数据发生改变的时候，我们要刷新缓存，避免脏数据的出现。刷新缓存的策略有两种，一种是定时刷新，一种手动刷新。
缓存数据的时机通常也分为两种，即在tomcat(web容器)启动时候加载数据进行缓存，另外也可以在用户第一次访问数据的时候进行缓存，这个相当于缓存的立即加载和按需加载。
缓存的层次如下:jsp-->action-->service-->dao,缓存越靠前对性能的提升越大
一个action里面可以有多个service,一个service中可以有多个dao或者多个service
任何类之间都可以进行相互调用，可以通过构造函数传参，set,get传参或者是方法传 参将相关的类连接起来。
九、OSCache+autocomplete+单例业务场景
在我以前做某项目的过程中，其中我们在做产品列表的查询的时候为了提高用户的体验度，我们使用了autocomplete插件来代替select进行品牌的选择，才开始的时候每次都要根据用户输入的信息去查询数据库进行模糊匹配返回结果，后来我们考虑到系统的性能，因此我们采用了oscache缓存，才开始这个功能是交给我们项目组中的另外一个同事来做的，但是他做完后，我们在使用这个工具类的时候，发现有时缓存中明明已经有时我们需要的数据，但是从缓存里面取的时候，发现没有，之后项目经理让我去帮这个同事看看这个问题，我经过阅读他的代码发现，它里面在使用缓存的时候，针对于每次方法的调用都产生一个新的实例，结果导致了上面的问题，这个时候我想起了可以使用设计模式中的单例模式来解决这个问题，才开始我直接采用了普通的单列模式，但是后来在测试的过程中，发现当用户并发量大的时候还是会出现上面的问题，之后我再次考虑了代码，最后发现是因为没有给单列模式加锁的原因，从而导致了大用户并发的时候，线程安全的问题，之后我便在方法上加上了synchronized关键字，解决上述的问题，但是后来测试人员反馈，觉的这段的性能有问题，我考虑之后便采用在方法体内加锁并结合双重判定的方式解决了上面的问题。我们是将数据在tomcat启动的时候加载到缓存中，之后用户进行查询的时候直接从缓存中获取数据，根据前缀匹配进行查询，将结果返回给用户。这样在提高用户体验度的同时也提高性能。
十、缓存概述
应用程序为了提高性能，可以通过使用缓存来达到目的，缓存的存储介质可以
内存或者硬盘，通常将数据存储在内存里，确切的说是jvm的内存中，缓存是
基于Map这种思想构建的，以键值对的方式进行存取，之所以还可以将
缓存的数据存储在硬盘中，是因为内存资源相当有限和宝贵，所以当内存资源
不足的时候，就可以将其存储到硬盘中，虽然硬盘的存取速度比内存要慢，但是
因为减少了网络通信量，所以还是提高程序的性能。缓存可以分为客户端缓存和
服务器端缓存，所谓的客户端缓存通常指的是IE浏览器的缓存，服务器端缓存指
的web服务器的缓存，通常可以通过第三方组件实现，如oscache,memcache
我们通常将那些频繁访问但是又不是经常改变的数据进行缓存。为了保证缓存数据的
有效性，在数据发生改变的时候，我们要刷新缓存，避免脏数据的出现。刷新缓存的
策略有两种，一种是定时刷新，一种手动刷新。
缓存的层次如下:jsp-->action-->service(通常放置在service)-->dao,
缓存越靠前对性能的提升越大
缓存的策略:(缓存空间不足需要进行清理的时候使用)
LRU:最近最少使用原则.(理解:存储书)
FIFO:先进先出的缓存策略.(理解:排队)
你来说说缓存？说说你对缓存的理解（如果遇到重复的，就可以省略）
我们在项目中使用缓存的目的是为了提高应用程序的性能，减少访问数据库
的次数，从而提高应用程序的吞吐量。我们通常将权限，菜单,组织机构
这些频繁访问但是不经常改变的基础数据进行缓存，其中我在做()某某项目的时候
就通过oscache对ZTree的树形菜单进行了缓存，并且在做的时候和单列设计
模式进行结合，考虑到多线程下的安全问题，还对单例模式加入了双重判定锁
的检查方式。
十一、实现页面静态化业务场景
我们在做某项目时，涉及到程序访问的性能问题，这时候我们想到可以通过静态化来提高用户访问时候的性能，所以我们就采用了freemarker模板引擎，考虑到页面也是要有动态的变化的，所以我们采用spring定时器在每天晚上2点钟的时候定时再次生成html静态页面，考虑发布时候的性能问题，我们又采取线程池技术，让多个线程同时发布，从而缩减发布时间。
十二、servlet线程安全描述
servlet是单列的，对于所有请求都使用一个实例，所以如果有全局变量被多
线程使用的时候，就会出现线程安全问题。
解决这个问题有三种方案:
1.实现singleThreadModel接口，这样对于每次请求都会创建一个新的servlet实例，这样就会消耗服务端内存，降低性能，但是这个接口已经过时，不推荐使用。
2.可以通过加锁(synchroniezd关键字)来避免线程安全问题。这个时候虽然还是单列，但是对于多线程的访问，每次只能有一个请求进行方法体内执行，只有执行完毕后，其他线程才允许访问，降低吞吐量。
3.避免使用全局变量，使用局部变量可以避免线程安全问题，强烈推荐使用此方法来解决servlet线程安全的问题。
十三、(jbpm4)工作流引擎描述:
JPBM是JBOSS旗下的一个开源的基于hibernate的工作流引擎。工作流就是在日常生活中，我们一些常见的如请假流程、采购流程、入职流程，通俗的来讲就是一些在现实生活中的流程以信息化以程序的方式实现。
一个工作流首先需要进行流程定义，流程定义是由节点和跳转组成的，节点又可以称为环节、活动节点、活动环节，并且节点也可以分为两大类型：人工节点和自动节点，人工节点有start开始节点、end结束节点、task任务节点，自动节点有decision判断节点、fork分支节点、join聚合节点和state状态节点，并且一个流程有且只有一个开始节点，但可以有多个结束节点。
流程定义是静止的，它在运行状态时会转换成流程实例，一个流程定义可以对应多个流程实例。流程运行后，会产生两个文件，*.jdpl.xml文件和*.png图片文件，也会生成18张数据库表，常用且核心的表有JBPM4_LOB 存储表，主要存储xml文件和png图片、JBPM4_TASK 任务表、JBPM4_EXECUTION 流程实例表、JBPM4_VARIABLE变量表。
图形化的灵活定制（主动说）
可以根据需求进行流程图的改变的，即定义的流程图是可以根据需要改变的，而不是死的。
可以进行图形化的监控(主动说)
输出图片
获取活动节点的坐标
进行叠加
判断节点:(主动说，也可以了解)
实现implements DecisionHandler接口并重写decide方法,
返回的字符串要和xml中配置的transition的name保持一致。
分支判定节点
JBPM有五大核心类：
ProcessEngine：主要获取各种的Service
RepositoryService：主要发布流程定义
ExecutionService：主要操作流程实例
TaskService：主要操作人工服务
HistoryService：主要操作历史服务。
核心方法：
读取jbpm定义的文件生成zip包存到lob表中：createDeployment()
获取流程定义列表：createProcessDefinitionQuery
根据定义的key或id来启动流程实例：startProcessInstanceByKey(id)
获取待办任务列表：findPersonalTasks(userName)
完成指定任务列表：completeTask(*.getActivityId())
获取历史任务列表：createHistoryTaskQuery()
获取流程实例的ID：task.getExecutionId()
(了解的表)
JBPM4_HIST_ACTINST 流程活动(节点) 实例表
JBPM4_HIST_DETAIL 流程历史详细表
JBPM4_HIST_PROCINST 流程实例历史表
JBPM4_HIST_TASK 流程任务实例历史表
JBPM4_HIST_VAR 流程变量( 上下文) 历史表
本文是业务场景篇--仍有下文，期待请关注
閱讀更多 動作要快姿勢要帥 的文章
