[note]现有的NoSQL数据库

* Cassandra
* Chordless
* CouchDB
* Db4o
* GT.M
* Hbase
* Hypertable
* Memcachedb
* Mnesia
* MongoDB
* Neo4j
* Project Voldemort
* Redis

[note]js执行函数的方法以及获取windows的特殊方法

代码：

function mm(){

   this.say=function(){

       alert("sss");

   }

}

m= new mm();

m['say']();

console.log([].sort.call());

console.log([]["sort"]["call"]());

 [].sort.call()就是window，因为sort函数，是对数组的排序。call函数如果没有参数就用全局对象。如果使用sort方法的对象没有可排列的数组那么返回对象本身。

[转][精品]浏览器缓存机制

Cache-Control

Cache-Control 是最重要的规则。这个字段用于指定所有缓存机制在整个请求/响应链中必须服从的指令。这些指令指定用于阻止缓存对请求或响应造成不利干扰的行为。这些指令通常覆盖默认缓存算法。缓存指令是单向的，即请求中存在一个指令并不意味着响应中将存在同一个指令。

cache-control 定义是：Cache-Control = "Cache-Control" ":" cache-directive。表 1 展示了适用的值。

表 1. 常用 cache-directive 值

Cache-directive	说明
public	所有内容都将被缓存
private	内容只缓存到私有缓存中
no-cache	所有内容都不会被缓存
no-store	所有内容都不会被缓存到缓存或 Internet 临时文件中
must-revalidation/proxy-revalidation	如果缓存的内容失效，请求必须发送到服务器/代理以进行重新验证
max-age=xxx (xxx is numeric)	缓存的内容将在 xxx 秒后失效

表 2 表明在不同的情形下，浏览器是将请求重新发送到服务器还是使用缓存的内容。

表 2. 对 cache-directive 值的浏览器响应

Cache-directive	打开一个新的浏览器窗口	在原窗口中单击 Enter 按钮	刷新	单击 Back 按钮
public	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器	浏览器呈现来自缓存的页面
private	浏览器重新发送请求到服务器	第一次，浏览器重新发送请求到服务器；此后，浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器	浏览器呈现来自缓存的页面
no-cache/no-store	浏览器重新发送请求到服务器	浏览器重新发送请求到服务器	浏览器重新发送请求到服务器	浏览器重新发送请求到服务器
must-revalidation/proxy-revalidation	浏览器重新发送请求到服务器	第一次，浏览器重新发送请求到服务器；此后，浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器	浏览器呈现来自缓存的页面
max-age=xxx (xxx is numeric)	在 xxx 秒后，浏览器重新发送请求到服务器	在 xxx 秒后，浏览器重新发送请求到服务器	浏览器重新发送请求到服务器	在 xxx 秒后，浏览器重新发送请求到服务器

Cache-Control 是关于浏览器缓存的最重要的设置，因为它覆盖其他设置，比如 Expires 和 Last-Modified。另外，由于浏览器的行为基本相同，这个属性是处理跨浏览器缓存问题的最有效的方法。

失效

Expires 头部字段提供一个日期和时间，响应在该日期和时间后被认为失效。失效的缓存条目通常不会被缓存（无论是代理缓存还是用户代理缓存）返回，除非首先通过原始服务器（或者拥有该实体的最新副本的中介缓存）验证。（注意：cache-control max-age 和 s-maxage 将覆盖 Expires 头部。）

Expires 字段接收以下格式的值：“Expires: Sun, 08 Nov 2009 03:37:26 GMT”。如果查看内容时的日期在给定的日期之前，则认为该内容没有失效并从缓存中提取出来。反之，则认为该内容失效，缓存将采取一些措施。表 3-6 表明针对不同用户操作的不同浏览器的行为。

表 3. 当用户打开一个新的浏览器窗口时的失效操作 

	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容没有失效	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 200	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面
内容失效	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

表 4. 当用户在原始浏览器窗口中单击 Enter 按钮时的失效操作

	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容没有失效	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304
内容失效	浏览器重新发送请求到服务器。返回代码是 200	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

表 5. 当用户按 F5 键刷新页面时的失效操作

	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容没有失效	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304
内容失效	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

表 6. 当用户单击 Back 或 Forward 按钮时的失效操作

	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容没有失效	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面
内容失效	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 200

注意：所有浏览器都假定为使用默认设置运行。

Last-Modified/E-Tag

Last-Modified 实体头部字段值通常用作一个缓存验证器。简单来说，如果实体值在 Last-Modified 值之后没有被更改，则认为该缓存条目有效。ETag 响应头部字段值是一个实体标记，它提供一个 “不透明” 的缓存验证器。这可能在以下几种情况下提供更可靠的验证：不方便存储修改日期；HTTP 日期值的 one-second 解决方案不够用；或者原始服务器希望避免由于使用修改日期而导致的某些冲突。

不同的浏览器有不同的配置行为。表 7-10 表明针对不同用户操作的不同浏览器的行为。

表 7. 当用户打开一个新的浏览器窗口时的 Last-Modified E-Tag 操作 

	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容自上次访问以来没有被修改	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304
内容自上次访问以来已经被修改	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

表 8. 当用户在原始浏览器窗口中单击 Enter 按钮时的 Last-Modified E-Tag 操作

	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容自上次访问以来没有被修改	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304
内容自上次访问以来已经被修改	浏览器重新发送请求到服务器。返回代码是 200	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

表 9. 当用户按 F5 键刷新页面时的 Last-Modified E-Tag 操作

	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容自上次访问以来没有被修改	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304	浏览器重新发送请求到服务器。返回代码是 304
内容自上次访问以来已经被修改	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

表 10. 没有缓存设置且用户单击 Back 或 Forward 按钮

	Firefox 3.5	IE 8	Chrome 3	Safari 4
内容自上次访问以来没有被修改	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面
内容自上次访问以来已经被修改	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器呈现来自缓存的页面	浏览器重新发送请求到服务器。返回代码是 200

注意：所有浏览器都假定使用默认设置运行。

不进行任何缓存相关设置

如果您不定义任何缓存相关设置，则不同的浏览器有不同的行为。有时，同一个浏览器在相同的情形下每次运行时的行为都是不同的。情况可能很复杂。另外，有些不该缓存的内容如果被缓存，将会导致安全问题。

不同的浏览器有不同的行为。表 11 展示了不同的浏览器行为。

表 11. 没有缓存设置且用户打开一个新的浏览器窗口

	Firefox 3.5	IE 8	Chrome 3	Safari 4
打开一个新页面	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200
在原始窗口中单击 Enter 按钮	浏览器重新发送请求到服务器。返回代码是 200	浏览器呈现来自缓存的页面。	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200
按 F5 键刷新	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200
单击 Back 或 Forward 按钮	浏览器呈现来自缓存的页面。	浏览器呈现来自缓存的页面。	浏览器重新发送请求到服务器。返回代码是 200	浏览器重新发送请求到服务器。返回代码是 200

注意：所有浏览器都假定使用默认设置运行。

[转][精品]Java的类装载器(Class Loader)和命名空间(NameSpace)

转自：http://blog.csdn.net/lovingprince/archive/2009/06/03/4239491.aspx

摘要

Java的类装载器是Java动态性的核心，本文将向大家简要介绍Java的类装载器，及相关的parent delegation模型，命名空间，运行时包等概念，同时讨论一些在学习中容易混淆的问题。

类装载器的功能及分类

顾名思义，类装载器是用来把类(class)装载进JVM的。JVM规范定义了两种类型的类装载器：启动内装载器(bootstrap)和用户自定义装载器(user-defined class loader)。

bootstrap是JVM自带的类装载器，用来装载核心类库，如java.lang.*等。由例1可以看出，java.lang.Object是由bootstrap装载的。

Java 提供了抽象类ClassLoader，所有用户自定义类装载器都实例化自ClassLoader的子类。 System Class Loader是一个特殊的用户自定义类装载器，由JVM的实现者提供，在编程者不特别指定装载器的情况下默认装载用户类。系统类装载器可以通过 ClassLoader.getSystemClassLoader() 方法得到。

例1，测试你所使用的JVM的ClassLoader

/*LoaderSample1.java*/
 public class LoaderSample1 {
     public static void main(String[] args) {
         Class c;
         ClassLoader cl;

        cl = ClassLoader.getSystemClassLoader();
         System.out.println(cl);

        while (cl != null) {
             cl = cl.getParent();
             System.out.println(cl);
         }
         try {
             c = Class.forName("java.lang.Object");
             cl = c.getClassLoader();
             System.out.println("java.lang.Object's loader is " + cl);
             c = Class.forName("LoaderSample1");
             cl = c.getClassLoader();
             System.out.println("LoaderSample1's loader is " + cl);
         } catch (Exception e) {
             e.printStackTrace();
         }
     }
 }

在我的机器上(Sun Java 1.4.2)的运行结果

 sun.misc.Launcher$AppClassLoader@1a0c10f
 sun.misc.Launcher$ExtClassLoader@e2eec8
 null 
 java.lang.Object's loader is null
 LoaderSample1's loader is sun.misc.Launcher$AppClassLoader@1a0c10f
 

第一行表示，系统类装载器实例化自类sun.misc.Launcher$AppClassLoader

第二行表示，系统类装载器的parent实例化自类sun.misc.Launcher$ExtClassLoader

第三行表示，系统类装载器parent的parent为bootstrap

第四行表示，核心类java.lang.Object是由bootstrap装载的

第五行表示，用户类LoaderSample1是由系统类装载器装载的

parent delegation模型

从 1.2版本开始，Java引入了双亲委托模型，从而更好的保证Java平台的安全。在此模型下，当一个装载器被请求装载某个类时，它首先委托自己的 parent去装载，若parent能装载，则返回这个类所对应的Class对象，若parent不能装载，则由parent的请求者去装载。

如 图1所示，loader2的parent为loader1，loader1的parent为system class loader。假设loader2被要求装载类MyClass，在parent delegation模型下，loader2首先请求loader1代为装载，loader1再请求系统类装载器去装载MyClass。若系统装载器能成 功装载，则将MyClass所对应的Class对象的reference返回给loader1，loader1再将reference返回给 loader2，从而成功将类MyClass装载进虚拟机。若系统类装载器不能装载MyClass，loader1会尝试装载MyClass，若 loader1也不能成功装载，loader2会尝试装载。若所有的parent及loader2本身都不能装载，则装载失败。

若 有一个能成功装载，实际装载的类装载器被称为定义类装载器，所有能成功返回Class对象的装载器（包括定义类装载器）被称为初始类装载器。如图1所示， 假设loader1实际装载了MyClass，则loader1为MyClass的定义类装载器，loader2和loader1为MyClass的初始 类装载器。

图 1 parent delegation模型

需 要指出的是，Class Loader是对象，它的父子关系和类的父子关系没有任何关系。一对父子loader可能实例化自同一个Class，也可能不是，甚至父loader实例 化自子类，子loader实例化自父类。假设MyClassLoader继承自ParentClassLoader，我们可以有如下父子loader：

ClassLoader loader1 = new MyClassLoader();
 //参数 loader1 为 parent
 ClassLoader loader2 = new ParentClassLoader(loader1); 
 

那么parent delegation模型为什么更安全了？因为在此模型下用户自定义的类装载器不可能装载应该由父亲装载器装载的可靠类，从而防止不可靠甚至恶意的代码代 替由父亲装载器装载的可靠代码。实际上，类装载器的编写者可以自由选择不用把请求委托给parent，但正如上所说，会带来安全的问题。

命名空间及其作用

每个类装载器有自己的命名空间，命名空间由所有以此装载器为创始类装载器的类组成。不同命名空间的两个类是不可见的，但只要得到类所对应的Class对象的reference，还是可以访问另一命名空间的类。

例 2演示了一个命名空间的类如何使用另一命名空间的类。在例子中，LoaderSample2由系统类装载器装载，LoaderSample3由自定义的装 载器loader负责装载，两个类不在同一命名空间，但LoaderSample2得到了LoaderSample3所对应的Class对象的 reference，所以它可以访问LoaderSampl3中公共的成员(如age)。

例2不同命名空间的类的访问

/*LoaderSample2.java*/
 import java.net.*;
 import java.lang.reflect.*;
 public class LoaderSample2 {
     public static void main(String[] args) {
         try {
             String path = System.getProperty("user.dir");
              URL[] us = {new URL("file://" + path + "/sub/")};
              ClassLoader loader = new URLClassLoader(us);
              Class c = loader.loadClass("LoaderSample3");
             Object o = c.newInstance();
              Field f = c.getField("age");
              int age = f.getInt(o);
             System.out.println("age is " + age);
         } catch (Exception e) {
             e.printStackTrace();
         }
     } 

} 

/*sub/Loadersample3.java*/
 public class LoaderSample3 {
     static {
         System.out.println("LoaderSample3 loaded");
     }
      public int age = 30;
 } 

编译：javac LoaderSample2.java; javac sub/LoaderSample3.java

运行：java LoaderSample2

LoaderSample3 loaded
  age is 30
 

从运行结果中可以看出，在类LoaderSample2中可以创建处于另一命名空间的类LoaderSample3中的对象并可以访问其公共成员age。

运行时包(runtime package)

由 同一类装载器定义装载的属于相同包的类组成了运行时包，决定两个类是不是属于同一个运行时包，不仅要看它们的包名是否相同，还要看的定义类装载器是否相 同。只有属于同一运行时包的类才能互相访问包可见的类和成员。这样的限制避免了用户自己的代码冒充核心类库的类访问核心类库包可见成员的情况。假设用户自 己定义了一个类java.lang.Yes，并用用户自定义的类装载器装载，由于java.lang.Yes和核心类库java.lang.*由不同的装 载器装载，它们属于不同的运行时包，所以java.lang.Yes不能访问核心类库java.lang中类的包可见的成员。

总结

在简单讨论了类装载器，parent delegation模型，命名空间，运行时包后，相信大家已经对它们的作用有了一定的了解。命名空间并没有完全禁止属于不同空间的类的互相访问，双亲委托模型加强了Java的安全，运行时包增加了对包可见成员的保护。