上下文

一、上下文加载器 要在项目中使用Spring框架，需要在web.xml做如下配置： <!--contextConfigLocation在 ContextLoaderListener类中的默认值是 /WEB-INF/applicationContext.xml--> <context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/applicationContext.xml</param-value> <!-- <param-value>classpath:applicationContext*.xml</param-value> --> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> 以下为类ContextLoaderListener的声明： public class ContextLoaderListener extends ContextLoader implements ServletContextListener{ // 上下文加载器 private

策略模式简介 策略模式一直程序开发中，最常用的模式之一；它的功能就是定义了一系列的算法，这些算法定义着公共的接口，所以它们之间可以相互替换。这使得我们在开发过程中，若有新的策略需要扩展时，程序变的很容易开发。下面是策略模式的结构示意图： 从结构示意图中，我们能清楚的感受到，策略模式的巧妙之处就是将变化的东西（这里我们称之为算法）通过定义一个相同的公共的接口封装且隔离；以不同的策略实现相同的接口，使程序能够完成各种任务的同时，让上层的编程针对接口，实现不变，也不关心其调用的是哪种策略。 上下文的引入 然而在实际开发中，我们的需求往往不会像结构示意图那样，如此简单、如此 simple 。实际较为常见的情况就是： 上层的调用需要与接口之间有一定的交互。 交互的可能是一些属性，或是一些方法。这样的交互往往会让接口变的难以调用；于是上下文的引入就是势在必行。将相关的属性或一些公共的方法封装到上下文中，让上下文去和接口进行复杂的交互。而上层的调用只需要跟上下文打交道就可以。下面有包含上下文的策略模式结构示意图： 仔细看看两个结构示意图的变化，其实不外乎将变的东西和不变的东西进行封装与隔离，这样不变的东西能够尽可能的减小其变化，而变的东西更容易修改或扩充；其实这也正是软件设计的基本原则。 透过示意图，我们上下文对象，将自己传递给接口，方便接口调取它的属性与方法，以完成交互

通常认为HTML页面是二维的，但实际上，CSS还有一个 z-index 属性，允许层叠元素。 所有的盒模型元素都处于三维坐标系中。 除了我们常用的横坐标和纵坐标， 盒模型元素还可以沿着“z轴”层叠摆放， 当他们相互覆盖时， z轴顺序就变得十分重要。 -- CSS 2.1 Section 9.9.1 - Layered presentation 默认的摆放规则 假定元素没有指定 z-index 属性，那么元素按照如下顺序叠放（从底到顶） 根元素的背景和边界 普通流(无定位)里的块元素(没有position或者position:static;)按HTML中的出现顺序堆叠 定位元素按HTML中的出现顺序堆叠 浮动 对于浮动的块元素来说，堆叠顺序变得有些不同。浮动块元素被放置于非定位块元素与定位块元素之间： 根元素的背景与边框 位于普通流中的后代块元素按照它们在 HTML 中出现的顺序堆叠 浮动块元素 常规流中的后代行内元素 后代中的定位元素按照它们在 HTML 中出现的顺序堆叠 使用 z-index 如果需要改变默认的摆放顺序，只需给元素指定 z-index 。 z-index 必须是整数，体现了元素在z轴的位置： 底层：距离观察者最远 …… -3 层 -2 层 -1 层 0 层 （默认） 1 层 2 层 3 层 …… 顶层：最接近观察者 没有指定 z-index 的时候

一、先说ServletContext 　　javaee标准规定了，servlet容器需要在应用项目启动时，给应用项目初始化一个ServletContext作为公共环境容器存放公共信息。ServletContext中的信息都是由容器提供的。 举例： 通过自定义contextListener获取web.xml中配置的参数 1.容器启动时，找到配置文件中的context-param作为键值对放到ServletContext中 2.然后找到listener，容器调用它的contextInitialized(ServletContextEvent event)方法，执行其中的操作 例如：在web.xml中配置 <context-param> <param-name>key</param-name> <param-value>value123</param-value> </context-param> <listener> <listener-class>com.brolanda.contextlistener.listener.ContextListenerTest</listener-class> </listener> 配置好之后，在该类中获取对应的参数信息 package com.brolanda.contextlistener.listener; import javax

在 关于类加载器 中已经介绍了Jvm的类加载机制，然而对于运行在Java EE容器中的Web应用来说，类加载器的实现方式与一般的Java应用有所不同。不同的Web容器的实现方式也会有所不同。 Tomcat中的类加载机制 在Apache Tomcat 中，为了提高系统的灵活性，引入了commonLoader、sharedLoader、catalinaLoader；为了支持和分隔多个web应用，使用了WebappClassLoader。下面以Tomcat7.0的类加载器结构图总体来看大致如下： Bootstrap | System | Common / \ Webapp1 Webapp2 ... Tomcat中的系统类加载器。Tomcat也是一个Java应用，他也是在最初系统提供的几层类加载器环境下运行起来的。那么Tomcat的一些最基本的类，也和其它简单Java应用一样，是通过系统的类加载器来加载的，比如默认配置下的tomcat/bin目录下的bootstrap.jar、tomcat-juli.jar、commons-daemon.jar这几个jar包中的类。 Tomcat的Common Loader。Common Loader是Tomcat在系统类加载器之上建立起来的，其父loader是系统类加载器。Common Loader负责上面几个jar包外的Tomcat的大部分java类

CPU上下文 在每个任务运行前，CPU 都需要知道任务从哪里加载、又从哪里开始运行，也就是说，需要系统事先帮它设置好 CPU 寄存器和程序计数器（Program Counter，PC）。 CPU 寄存器，是 CPU 内置的容量小、但速度极快的内存。而程序计数器，则是用来存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置。它们都是 CPU 在运行任何任务前，必须的依赖环境，因此也被叫做 CPU 上下文。 CPU 上下文切换 就是先把前一个任务的 CPU 上下文（也就是 CPU 寄存器和程序计数器）保存起来 加载新任务的上下文到这些寄存器和程序计数器 跳转到程序计数器所指的新位置，运行新任务。 根据任务的不同，CPU 的上下文切换就可以分为几个不同的场景，也就是进程上下文切换、线程上下文切换以及中断上下文切换。 进程和线程 进程是资源分配和执行的基本单位；线程是任务调度和运行的基本单位。线程没有资源，进程给指针提供虚拟内存、栈、变量等共享资源，而线程可以共享进程的资源。 进程上下文切换 Linux 按照特权等级，把进程的运行空间分为内核空间和用户空间。 CPU 特权等级的 Ring 0 和 Ring 3。 内核空间（Ring 0）具有最高权限，可以直接访问所有资源；用户空间（Ring 3）只能访问受限资源，不能直接访问内存等硬件设备，必须通过系统调用陷入到内核中

1.js的作用域是有函数划分的，而不是块儿 var too="test"; if(true){//这是在块中的定义，此时还是全局变量 var too="new test"; } alert(too=="new test");//return true; function test() { var too="old test";//这是在函数中的定义，此时是局部变量 } test（）； alert(too=="new test");//return true;too并没有改变 2.所有属于全局作用域的变量都是window对象的属性 上面例子中 第一行的 too就是等于 window.too 看下面的例子 function test() { too="test"; } test(); alert(window.too="test"); 是不是很奇怪，上面例子中函数中的too是局部变量，在这里就是全局变量了 注意下两个例子的区别，一个通过显示声明 var too 一个隐示声明too="test"； 也就是说没有显示定义的变量，它就是全局变量，虽然它可能只能在这个函数内使用。 作用域（scope）是JavaScript语言的基石之一，在构建复杂程序时也可能是最令我头痛的东西。记不清多少次在函数之间传递控制后忘记 this关键字引用的究竟是哪个对象，甚至，我经常以各种不同的混乱方式来曲线救国

data-bind 语法 knockout 声明式绑定系统提供了一种简洁而强大的方式将数据链接到UI。绑定到简单的数据属性或使用单个绑定通常是简单而明显的。对于更复杂的绑定，它有助于更好地理解 knockout 绑定系统的行为和语法。 绑定语法 绑定由两个项组成，绑定 名称 和 值 ，用冒号分隔。下面是单个简单绑定的示例 Today's message is: <span data-bind="text: myMessage"></span> 元素可以包含多个绑定(相关的或不相关的)，每个绑定之间用逗号分隔。下面是一些例子 <!-- 相关绑定:valueUpdate是值的参数 --> Your value: <input data-bind="value: someValue, valueUpdate: 'afterkeydown'" /> <!-- 不相关绑定 --> Cellphone: <input data-bind="value: cellphoneNumber, enable: hasCellphone" /> 绑定名称通常应匹配已注册的绑定(内置或自定义)，或作为另一个绑定的参数。如果名称与这两个名称都不匹配，则 knockout 将忽略它(没有任何错误或警告)。因此， 如果绑定似乎不起作用，首先检查名称是否正确。 绑定值 绑定值可以是 （ value,

转载请注明原文地址： https://www.cnblogs.com/ygj0930/p/10843676.html 一： 什么是上下文切换 CPU处理任务时不是一直只处理一个，而是通过给每个线程分配CPU时间片，时间片用完了就切换下一个线程。时间片非常短，一般只有几十毫秒，所以CPU通过不停地切换线程执行时我们几乎感觉不到任务的停滞，让我们感觉是多个线程同时执行。 CPU通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个任务。但是，在切换前会保存上一个任务的状态，以便下次切换回这个任务时，可以再次加载这个任务的状态， 从任务保存到再加载的过程就是一次上下文切换 。 这样的切换是会影响多线程的执行效率的。 二： 如何减少上下文切换来提高多线程程序的运行效率 线程的上下文切换分为 让步式上下文切换 和 抢占式上下文切换 。 前者是指执行线程主动释放CPU，与锁竞争严重程度成正比，可通过 减少锁竞争来避免 ； 后者是指线程因分配的时间片用尽而被迫放弃CPU或者被其他优先级更高的线程所抢占，一般由于线程数大于CPU可用核心数引起，可通过 调整线程数， 适当减少线程数来避免。 1） 无锁并发编程 。锁竞争时会引起上下文切换，所以多线程处理数据时，可以用一些办法来避免使用锁，如将数据的ID按照Hash取模分段，不同的线程处理不同段的数据。 2）减少锁的使用，能

什么是上下文切换 上下文切换（context-switching）是存储和恢复CPU状态的过程，它使得线程执行能够从中断点恢复执行。 上下文切换时多任务操作系统和多线程环境的基本特征。 即使是单核CPU也支持多线程执行代码，CPU通过给每个线程分配CPU时间片来实现这个机制。时间片是CPU分配给各个线程的时间，因为时间片非常短，所以CPU通过不停地切换线程执行，让我们感觉多个线程时同时执行的，时间片一般是几十毫秒（ms）。 CPU通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个任务。但是，在切换前会保存上一个任务的状态，以便下次切换回这个任务时，可以再次加载这个任务的状态， 从任务保存到再加载的过程就是一次上下文切换 。 这就像我们同时读两本书，当我们在读一本英文的技术书籍时，发现某个单词不认识， 于是便打开中英文词典，但是在放下英文书籍之前，大脑必须先记住这本书读到了多少页的第多少行，等查完单词之后，能够继续读这本书。这样的切换是会影响读 书效率的，同样上下文切换也会影响多线程的执行速度。 如何减少上下文切换 既然上下文切换会导致额外的开销，因此减少上下文切换次数便可以提高多线程程序的运行效率。减少上下文切换的方法有无锁并发编程、CAS算法、使用最少线程和使用协程。 无锁并发编程 。多线程竞争时，会引起上下文切换，所以多线程处理数据时