惟严禅师说：“云在青天水在瓶”
正如眼横鼻直，日东升西落一样，都是事物的自然常态，没有什么特别的地方。
你只要领会事物的本质、悟见自己本来面目，也就明白什么是道了。
犹如人的心一样，只要保持清净不染，心就像水一样清澈，不论装在什么瓶中，都能随方就圆，有很强的适应能力，能刚能柔，能大能小，就像青天的白云一样，自由自在。
2009年4月14日星期二
Java 理论与实践: 并发集合类（转）
DougLea的 util.concurrent 包除了包含许多其他有用的并发构造块之外，还包含了一些主要集合类型 List 和 Map 的高性能的、线程安全的实现。在本月的 Java理论与实践中，BrianGoetz向您展示了用 ConcurrentHashMap 替换 Hashtable 或 synchronizedMap ，将有多少并发程序获益。您可以在本文的 论坛中与作者以及其他读者共享您的想法（您也可以点击文章顶部或者底部的 讨论进入论坛）。
在Java类库中出现的第一个关联的集合类是 Hashtable ，它是JDK 1.0的一部分。 Hashtable 提供了一种易于使用的、线程安全的、关联的map功能，这当然也是方便的。然而，线程安全性是凭代价换来的―― Hashtable 的所有方法都是同步的。此时，无竞争的同步会导致可观的性能代价。 Hashtable 的后继者 HashMap 是作为JDK1.2中的集合框架的一部分出现的，它通过提供一个不同步的基类和一个同步的包装器 Collections.synchronizedMap ，解决了线程安全性问题。通过将基本的功能从线程安全性中分离开来， Collections.synchronizedMap 允许需要同步的用户可以拥有同步，而不需要同步的用户则不必为同步付出代价。
Hashtable 和 synchronizedMap 所采取的获得同步的简单方法（同步 Hashtable 中或者同步的 Map 包装器对象中的每个方法）有两个主要的不足。首先，这种方法对于可伸缩性是一种障碍，因为一次只能有一个线程可以访问hash表。同时，这样仍不足以提供真正的线程安全性，许多公用的混合操作仍然需要额外的同步。虽然诸如 get() 和 put() 之类的简单操作可以在不需要额外同步的情况下安全地完成，但还是有一些公用的操作序列，例如迭代或者put-if-absent（空则放入），需要外部的同步，以避免数据争用。
有条件的线程安全性
同步的集合包装器 synchronizedMap 和 synchronizedList ，有时也被称作 有条件地线程安全――所有单个的操作都是线程安全的，但是多个操作组成的操作序列却可能导致数据争用，因为在操作序列中控制流取决于前面操作的结果。 清单1中第一片段展示了公用的put-if-absent语句块――如果一个条目不在 Map 中，那么添加这个条目。不幸的是，在 containsKey() 方法返回到 put() 方法被调用这段时间内，可能会有另一个线程也插入一个带有相同键的值。如果您想确保只有一次插入，您需要用一个对 Map m 进行同步的同步块将这一对语句包装起来。
清单1中其他的例子与迭代有关。在第一个例子中， List.size() 的结果在循环的执行期间可能会变得无效，因为另一个线程可以从这个列表中删除条目。如果时机不得当，在刚好进入循环的最后一次迭代之后有一个条目被另一个线程删除了，则 List.get() 将返回 null ，而 doSomething() 则很可能会抛出一个 NullPointerException 异常。那么，采取什么措施才能避免这种情况呢？如果当您正在迭代一个 List 时另一个线程也可能正在访问这个 List ，那么在进行迭代时您必须使用一个 synchronized 块将这个 List 包装起来，在 List 1 上同步，从而锁住整个 List 。这样做虽然解决了数据争用问题，但是在并发性方面付出了更多的代价，因为在迭代期间锁住整个 List 会阻塞其他线程，使它们在很长一段时间内不能访问这个列表。
集合框架引入了迭代器，用于遍历一个列表或者其他集合，从而优化了对一个集合中的元素进行迭代的过程。然而，在 java.util 集合类中实现的迭代器极易崩溃，也就是说，如果在一个线程正在通过一个 Iterator 遍历集合时，另一个线程也来修改这个集合，那么接下来的 Iterator.hasNext() 或 Iterator.next() 调用将抛出 ConcurrentModificationException 异常。就拿刚才这个例子来讲，如果想要防止出现 ConcurrentModificationException 异常，那么当您正在进行迭代时，您必须使用一个在 List l 上同步的 synchronized 块将该 List 包装起来，从而锁住整个 List 。（或者，您也可以调用 List.toArray() ，在不同步的情况下对数组进行迭代，但是如果列表比较大的话这样做代价很高）。
清单 1. 同步的map中的公用竞争条件
Map m = Collections.synchronizedMap(new HashMap());
List l = Collections.synchronizedList(new ArrayList());
// put-if-absent idiom -- contains a race condition
// may require external synchronization
if (!map.containsKey(key))
map.put(key, value);
// ad-hoc iteration -- contains race conditions
// may require external synchronization
for (int i=0; i
doSomething(list.get(i));
}
// normal iteration -- can throw ConcurrentModificationException
// may require external synchronization
for (Iterator i=list.iterator(); i.hasNext(); ) {
doSomething(i.next());
}
信任的错觉
synchronizedList 和 synchronizedMap 提供的有条件的线程安全性也带来了一个隐患 ―― 开发者会假设，因为这些集合都是同步的，所以它们都是线程安全的，这样一来他们对于正确地同步混合操作这件事就会疏忽。其结果是尽管表面上这些程序在负载较轻的时候能够正常工作，但是一旦负载较重，它们就会开始抛出 NullPointerException 或 ConcurrentModificationException 。
可伸缩性问题
可伸缩性指的是一个应用程序在工作负载和可用处理资源增加时其吞吐量的表现情况。一个可伸缩的程序能够通过使用更多的处理器、内存或者I/O带宽来相应地处理更大的工作负载。锁住某个共享的资源以获得独占式的访问这种做法会形成可伸缩性瓶颈――它使其他线程不能访问那个资源，即使有空闲的处理器可以调用那些线程也无济于事。为了取得可伸缩性，我们必须消除或者减少我们对独占式资源锁的依赖。
同步的集合包装器以及早期的 Hashtable 和 Vector 类带来的更大的问题是，它们在单个的锁上进行同步。这意味着一次只有一个线程可以访问集合，如果有一个线程正在读一个 Map ，那么所有其他想要读或者写这个 Map 的线程就必须等待。最常见的 Map 操作， get() 和 put() ，可能比表面上要进行更多的处理――当遍历一个hash表的bucket以期找到某一特定的key时， get() 必须对大量的候选bucket调用 Object.equals() 。如果key类所使用的 hashCode() 函数不能将value均匀地分布在整个hash表范围内，或者存在大量的hash冲突，那么某些bucket链就会比其他的链长很多，而遍历一个长的hash链以及对该hash链上一定百分比的元素调用 equals() 是一件很慢的事情。在上述条件下，调用 get() 和 put() 的代价高的问题不仅仅是指访问过程的缓慢，而且，当有线程正在遍历那个hash链时，所有其他线程都被锁在外面，不能访问这个 Map 。
（哈希表根据一个叫做hash的数字关键字（key）将对象存储在bucket中。hash value是从对象中的值计算得来的一个数字。每个不同的hash value都会创建一个新的bucket。要查找一个对象，您只需要计算这个对象的hash value并搜索相应的bucket就行了。通过快速地找到相应的bucket，就可以减少您需要搜索的对象数量了。译者注）
get() 执行起来可能会占用大量的时间，而在某些情况下，前面已经作了讨论的有条件的线程安全性问题会让这个问题变得还要糟糕得多。 清单1 中演示的争用条件常常使得对单个集合的锁在单个操作执行完毕之后还必须继续保持一段较长的时间。如果您要在整个迭代期间都保持对集合的锁，那么其他的线程就会在锁外停留很长的一段时间，等待解锁。
实例：一个简单的cache
Map 在服务器应用中最常见的应用之一就是实现一个 cache。 服务器应用可能需要缓存文件内容、生成的页面、数据库查询的结果、与经过解析的XML文件相关的DOM树，以及许多其他类型的数据。cache的主要用途是重用前一次处理得出的结果以减少服务时间和增加吞吐量。cache工作负载的一个典型的特征就是检索大大多于更新，因此（理想情况下）cache能够提供非常好的 get() 性能。不过，使用会妨碍性能的cache还不如完全不用cache。
如果使用 synchronizedMap 来实现一个cache，那么您就在您的应用程序中引入了一个潜在的可伸缩性瓶颈。因为一次只有一个线程可以访问 Map ，这些线程包括那些要从 Map 中取出一个值的线程以及那些要将一个新的 (key, value) 对插入到该map中的线程。
减小锁粒度
提高 HashMap 的并发性同时还提供线程安全性的一种方法是废除对整个表使用一个锁的方式，而采用对hash表的每个bucket都使用一个锁的方式（或者，更常见的是，使用一个锁池，每个锁负责保护几个bucket）。这意味着多个线程可以同时地访问一个 Map 的不同部分，而不必争用单个的集合范围的锁。这种方法能够直接提高插入、检索以及移除操作的可伸缩性。不幸的是，这种并发性是以一定的代价换来的――这使得对整个集合进行操作的一些方法（例如 size() 或 isEmpty() ）的实现更加困难，因为这些方法要求一次获得许多的锁，并且还存在返回不正确的结果的风险。然而，对于某些情况，例如实现cache，这样做是一个很好的折衷――因为检索和插入操作比较频繁，而 size() 和 isEmpty() 操作则少得多。
ConcurrentHashMap
util.concurrent 包中的 ConcurrentHashMap 类（也将出现在JDK 1.5中的 java.util.concurrent 包中）是对 Map 的线程安全的实现，比起 synchronizedMap 来，它提供了好得多的并发性。多个读操作几乎总可以并发地执行，同时进行的读和写操作通常也能并发地执行，而同时进行的写操作仍然可以不时地并发进行（相关的类也提供了类似的多个读线程的并发性，但是，只允许有一个活动的写线程） 。ConcurrentHashMap 被设计用来优化检索操作；实际上，成功的 get() 操作完成之后通常根本不会有锁着的资源。要在不使用锁的情况下取得线程安全性需要一定的技巧性，并且需要对Java内存模型（Java Memory Model）的细节有深入的理解。 ConcurrentHashMap 实现，加上 util.concurrent 包的其他部分，已经被研究正确性和线程安全性的并发专家所正视。在下个月的文章中，我们将看看 ConcurrentHashMap 的实现的细节。
ConcurrentHashMap 通过稍微地松弛它对调用者的承诺而获得了更高的并发性。检索操作将可以返回由最近完成的插入操作所插入的值，也可以返回在步调上是并发的插入操作所添加的值（但是决不会返回一个没有意义的结果）。由 ConcurrentHashMap.iterator() 返回的 Iterators 将每次最多返回一个元素，并且决不会抛出 ConcurrentModificationException 异常，但是可能会也可能不会反映在该迭代器被构建之后发生的插入操作或者移除操作。在对集合进行迭代时，不需要表范围的锁就能提供线程安全性。在任何不依赖于锁整个表来防止更新的应用程序中，可以使用 ConcurrentHashMap 来替代 synchronizedMap 或 Hashtable 。
上述改进使得 ConcurrentHashMap 能够提供比 Hashtable 高得多的可伸缩性，而且，对于很多类型的公用案例（比如共享的cache）来说，还不用损失其效率。
好了多少？
表 1对 Hashtable 和 ConcurrentHashMap 的可伸缩性进行了粗略的比较。在每次运行过程中， n 个线程并发地执行一个死循环，在这个死循环中这些线程从一个 Hashtable 或者 ConcurrentHashMap 中检索随机的key value，发现在执行 put() 操作时有80%的检索失败率，在执行操作时有1%的检索成功率。测试所在的平台是一个双处理器的Xeon系统，操作系统是Linux。数据显示了10,000,000次迭代以毫秒计的运行时间，这个数据是在将对 ConcurrentHashMap的 操作标准化为一个线程的情况下进行统计的。您可以看到，当线程增加到多个时， ConcurrentHashMap 的性能仍然保持上升趋势，而 Hashtable 的性能则随着争用锁的情况的出现而立即降了下来。
比起通常情况下的服务器应用，这次测试中线程的数量看上去有点少。然而，因为每个线程都在不停地对表进行操作，所以这与实际环境下使用这个表的更多数量的线程的争用情况基本等同。
表 1.Hashtable 与 ConcurrentHashMap在可伸缩性方面的比较
线程数 ConcurrentHashMap Hashtable
1 1.00 1.03
2 2.59 32.40
4 5.58 78.23
8 13.21 163.48
16 27.58 341.21
32 57.27 778.41
CopyOnWriteArrayList
在那些遍历操作大大地多于插入或移除操作的并发应用程序中，一般用 CopyOnWriteArrayList 类替代 ArrayList 。如果是用于存放一个侦听器（listener）列表，例如在AWT或Swing应用程序中，或者在常见的JavaBean中，那么这种情况很常见（相关的 CopyOnWriteArraySet 使用一个 CopyOnWriteArrayList 来实现 Set 接口）。
如果您正在使用一个普通的 ArrayList 来存放一个侦听器列表，那么只要该列表是可变的，而且可能要被多个线程访问，您就必须要么在对其进行迭代操作期间，要么在迭代前进行的克隆操作期间，锁定整个列表，这两种做法的开销都很大。当对列表执行会引起列表发生变化的操作时， CopyOnWriteArrayList 并不是为列表创建一个全新的副本，它的迭代器肯定能够返回在迭代器被创建时列表的状态，而不会抛出 ConcurrentModificationException 。在对列表进行迭代之前不必克隆列表或者在迭代期间锁定列表，因为迭代器所看到的列表的副本是不变的。换句话说， CopyOnWriteArrayList 含有对一个不可变数组的一个可变的引用，因此，只要保留好那个引用，您就可以获得不可变的线程安全性的好处，而且不用锁定列表。
结束语
同步的集合类 Hashtable 和 Vector ，以及同步的包装器类 Collections.synchronizedMap 和 Collections.synchronizedList ，为 Map 和 List 提供了基本的有条件的线程安全的实现。然而，某些因素使得它们并不适用于具有高度并发性的应用程序中――它们的集合范围的单锁特性对于可伸缩性来说是一个障碍，而且，很多时候还必须在一段较长的时间内锁定一个集合，以防止出现 ConcurrentModificationException s异常。 ConcurrentHashMap 和 CopyOnWriteArrayList 实现提供了更高的并发性，同时还保住了线程安全性，只不过在对其调用者的承诺上打了点折扣。 ConcurrentHashMap 和 CopyOnWriteArrayList 并不是在您使用 HashMap 或 ArrayList 的任何地方都一定有用，但是它们是设计用来优化某些特定的公用解决方案的。许多并发应用程序将从对它们的使用中获得好处。
参考资料
您可以参阅本文在 developerWorks 全球站点上的 英文原文.
参与有关本文的 论坛（您也可以单击文章顶部或底部的 讨论来访问论坛）。
阅读由Brian Goetz撰写的 完整的 Java 理论与实践 系列。特别地，在“ 变化，还是不变化?” ( developerworks, 2003年2月)一文中还讨论了不变性的线程安全性好处。
Doug Lea的 Concurrent Programming in Java, Second Edition 这本书对有关Java应用程序中的多线程编程中的一些微妙的问题作了精妙的论述。
下载 util.concurrent 包。
ConcurrentHashMap 的javadoc页面更详细地解释了 ConcurrentHashMap 和 Hashtable 之间的不同之处。
JSR 166 是用于JDK 1.5的标准化的 util.concurrent 库。
2002年11月那一期的 Java 理论与实践研究了 util.concurrent的执行工具。
“ 轻松线程化，第二部分” ( developerWorks, 2001年9月)中探讨了争用所致的代价。
在 developerWorks Java 技术专区 ，可以找到数百篇有关Java编程各方面的文章。
关于作者
在过去的15年中，Brian Goetz 一直都是一个职业软件开发者。他是 Quiotix公司的首席顾问，这家公司从事软件开发与咨询业务，位于加利福尼亚州的洛斯拉图斯，而且，他还在一些JCP专家组（JCP Expert Group）中担任职务。在业内流行的出版物中参阅Brian 已发表的和即将发表的文章。可以通过 brian@quiotix.com与Brian联系。
2009年4月7日星期二
饮食
最健康食品
最佳蔬菜：番薯、芦笋、卷心菜、花椰菜、芹菜、茄子、甜菜、胡萝卜、荠菜、芥兰菜、金针菇、雪菜、大白菜。
最佳水果：木瓜、草莓、橘子、柑子、猕猴桃、芒果、杏、柿子、西瓜。
最佳肉食：鹅、鸭、鸡。
最佳食油：玉米油、米糠油、芝麻油。
最佳汤食：鸡汤。
最佳护脑食物：菠菜、韭菜、南瓜、葱、花椰菜、菜椒、豌豆、番茄、胡萝卜、小青菜、蒜苗、芹菜等蔬菜;核桃、花生、开心果、腰果、松子、杏仁、大豆等。
十大垃圾食品
油炸类食品：导致心血管疾病的元凶;含致癌物质;破坏维生素。
腌渍类食品：导致高血压，肾负担过重;导致鼻咽癌;影响粘膜系统。
加工类肉食品(肉干、肉松、香肠等)：含致癌物亚硝酸盐;含损肝的防腐剂。
饼干类食品(不含低温烘烤和全麦饼干)：食用香精和色素过多，损肝;严重破坏维生素。
汽水可乐类食品：含磷酸、碳酸，会带走体内的钙;含糖量过高。
方便类食品(主要指方便面和膨化食品)：盐分过高，含损肝的防腐剂、香精;只有热量，没有营养。
罐头类食品(包括鱼肉类和水果类)：破坏维生素，使蛋白质变性;热量过多，营养成分低。
话梅蜜饯类食品(果脯)：含致癌物亚硝酸盐;盐分过高，含损肝的防腐剂、香精。
冷冻甜品类食品(冰淇淋、冰棒和雪糕)：含奶油极易引起肥胖;含糖量过高，影响正餐。
烧烤类食品：含致癌物三苯四丙羁;导致蛋白质炭化变性，损肝肾。
最佳蔬菜：番薯、芦笋、卷心菜、花椰菜、芹菜、茄子、甜菜、胡萝卜、荠菜、芥兰菜、金针菇、雪菜、大白菜。
最佳水果：木瓜、草莓、橘子、柑子、猕猴桃、芒果、杏、柿子、西瓜。
最佳肉食：鹅、鸭、鸡。
最佳食油：玉米油、米糠油、芝麻油。
最佳汤食：鸡汤。
最佳护脑食物：菠菜、韭菜、南瓜、葱、花椰菜、菜椒、豌豆、番茄、胡萝卜、小青菜、蒜苗、芹菜等蔬菜;核桃、花生、开心果、腰果、松子、杏仁、大豆等。
十大垃圾食品
油炸类食品：导致心血管疾病的元凶;含致癌物质;破坏维生素。
腌渍类食品：导致高血压，肾负担过重;导致鼻咽癌;影响粘膜系统。
加工类肉食品(肉干、肉松、香肠等)：含致癌物亚硝酸盐;含损肝的防腐剂。
饼干类食品(不含低温烘烤和全麦饼干)：食用香精和色素过多，损肝;严重破坏维生素。
汽水可乐类食品：含磷酸、碳酸，会带走体内的钙;含糖量过高。
方便类食品(主要指方便面和膨化食品)：盐分过高，含损肝的防腐剂、香精;只有热量，没有营养。
罐头类食品(包括鱼肉类和水果类)：破坏维生素，使蛋白质变性;热量过多，营养成分低。
话梅蜜饯类食品(果脯)：含致癌物亚硝酸盐;盐分过高，含损肝的防腐剂、香精。
冷冻甜品类食品(冰淇淋、冰棒和雪糕)：含奶油极易引起肥胖;含糖量过高，影响正餐。
烧烤类食品：含致癌物三苯四丙羁;导致蛋白质炭化变性，损肝肾。
2009年3月29日星期日
struts2中action之间传递参数（转）
首先：在action类中给rquest设置一个属性：
例如：
String catalogid = ServletActionContext.getRequest().getParameter("catalogid");
ServletActionContext.getRequest().setAttribute("catalogid", catalogid);
接着：在action配置中配置url
这样就可以在addSubCatalog里面用url传递的参数了
在这个配置文件里，多个参数的连接符使用了"&"，但XML的语法规范，应该使用"&"代替"&"，原理和HTML中的转义相同，开始没有注意，在struts分析配置文件时，总是报出这样的错误
2009年3月12日星期四
在批处理中等待／延迟／暂停一定的时间
1、暂停（Pause）、延迟（Delay）、等待（Wait）、睡眠（Sleep）
1)for+set+if，时间精度为0.01秒，适用平台为WinNT/2K/XP/2003。
利用for解析变量%time%并存为两个时间点%start%和%now%，再利用set /a计算两个时间点的时间差，最后用if判断时间差是否达到设定的暂停时间。
2)VBS脚本中的sleep函数，时间精度为0.001秒，使用平台为Win9x/WinNT系列。@echo off
setlocal enableextensions
echo %time%
call :ProcDelay 200
echo %time%
goto :EOF
:ProcDelay delayMSec_
setlocal enableextensions
for /f "tokens=1-4 delims=:. " %%h in ("%time%") do set start_=%%h%%i%%j%%k
:_procwaitloop
for /f "tokens=1-4 delims=:. " %%h in ("%time%") do set now_=%%h%%i%%j%%k
set /a diff_=%now_%-%start_%
if %diff_% LSS %1 goto _procwaitloop
endlocal & goto :EOF
动态创建一个调用sleep()函数的VBS脚本，然后用Windows脚本宿主的命令行版本cscript调用它。
3)ping的消息发送间隔，时间精度为1秒，使用平台为Win9x/WinNT系列。@echo off & setlocal enableextensions enabledelayedexpansion
echo WScript.Sleep 2000 > %temp%\tmp$$$.vbs
echo %time%
cscript //nologo %temp%\tmp$$$.vbs
echo %time%
for %%f in (%temp%\tmp$$$.vbs) do if exist %%f del %%f
endlocal & goto :EOF
需要你的Windows系统中正常安装了网卡的TCP/IP协议，有两种方案：
(1) 利用ping两次发送消息之间的间隔时间。ping在发送多个消息时，在得到上一次消息的回应后，它会再等待1秒的时间才发送下一次消息，而这个回应时间 因机型、系统和网络配置而不同，其中IP地址尤其关键，只有本地的回送地址 127.0.0.1 因为是立即回应所以才是相对恒定的，其他地址大多会产生显著的差异。此种方法要等待更大的时间，是指定发送的消息数为等待的时间加一，因为第一个消息是不 等待的，IP 地址必须是 127.0.0.1 。其等待2秒的程序如下：
(2) 利用ping的最大等待时间。ping向0.0.0.1发送一次“网际消息控制协议 (ICMP)”回响请求消息，因为 0.0.0.1 是个无法响应 ping 请求的IP地址，所以默认情况下，ping会等待一定的最大响应时间——4秒后便停止等待，而-w可以改变这个每发送一次消息所等待的最大响应时间。而如 果将 IP 地址改为立即响应的127.0.0.1或其他响应时间很短的IP ，那 -w 便失去了作用，因为每次发送等待时间都不会达到最大的响应时间，此时延时会缩短。此种方法要等待更大的时间，可以直接使用 -w 指定，但是需要减去 500 毫秒（原因尚未知），而且 IP 地址必须是不响应请求的地址。其等待2秒的程序如下：::根据植树原则，n后的数字为暂停秒数加一
ping -n 3 127.0.0.1>nul
4)choice的缺省选择等待功能，时间精度为1秒，适用平台为MS-DOS/Win9x/WinNT系列。ping -n 2 -w 500 0.0.0.1>nul
/t:y,2 将缺省选择字符设置为y，等待时间是2秒，/n禁止[y,n]提示出现在命令行上，“rem|”的作用是禁止choice从键盘接受按键，从而暂停不会因为按下y或者其它键而被意外终止。
5)ASCII汇编代码，延迟精度为0.001秒，适用平台为MS-DOS/Win9x/WinNT。rem|choice /t:y,2 /n >nul
德国人Herbert Kleebauer给出了一个通用方案，通过ASCII汇编器间接产生一个sleep.exe程序来实现延迟，这个程序分为DOS和Win两个模块，分别调用DOS系统中断服务和WindowsAPI。
:: Sleep.bat - Sleep/Delay/Wait n seconds
:: Herbert Kleebauer(Germany) - 2005/05/29
:: Modified by Will Sort - 2005/06/02, 07-25
@echo off
echo q | debug>nul
echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>sleep.com
echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>sleep.com
echo T}{z~~@GwkBG@OEKcUt`~}@MqqBsy?seHB~_Phxr?@zAB`LrPEyoDt@Cj?>>sleep.com
echo pky_jN@QEKpEt@ij?jySjN@REKpEt@jj?jyGjN@SEKkjtlGuNw?p@pjirz>>sleep.com
echo LFvAURQ?OYLTQ@@?~QCoOL~RDU@?aU?@{QOq?@}IKuNWpe~FpeQFwH?Vkk>>sleep.com
echo _GSqoCvH{OjeOSeIQRmA@KnEFB?p??mcjNne~B?M??QhetLBgBPHexh@e=>>sleep.com
echo EsOgwTLbLK?sFU`?LDOD@@K@xO?SUudA?_FKJ@N?KD@?UA??O}HCQOQ??R>>sleep.com
echo _OQOL?CLA?CEU?_FU?UAQ?UBD?LOC?ORO?UOL?UOD?OOI?UgL?LOR@YUO?>>sleep.com
echo dsmSQswDOR[BQAQ?LUA?_L_oUNUScLOOuLOODUO?UOE@OwH?UOQ?DJTSDM>>sleep.com
echo QTqrK@kcmSULkPcLOOuLOOFUO?hwDTqOsTdbnTQrrDsdFTlnBTm`lThKcT>>sleep.com
echo @dmTkRQSoddTT~?K?OCOQp?o??Gds?wOw?PGAtaCHQvNntQv_w?A?it\EH>>sleep.com
echo {zpQpKGk?Jbs?FqokOH{T?jPvP@IQBDFAN?OHROL?Kj??pd~aN?OHROd?G>>sleep.com
echo Q??PGT~B??OC~?ipO?T?~U?p~cUo0x>>sleep.com
sleep.com>sleep.exe
echo wait %1 seconds:
sleep.exe %1000
del sleep.com
del sleep.exe
批处理延时方法小结:
1.ping
内存使用: cmd.exe 1704k@echo off
:loop
echo %time%
ping 127.1 -n 2 1>nul
echo %time%
goto loop
ping.exe 2920k
误差评定: 较高
优点: 代码构造简单
缺点: 内存占用高，延迟时间长的话误差相对较大。
2.还是ping
内存使用: cmd.exe 1700k@echo off
:loop
echo %time%
ping 1 -n 1 -w 1000 2>nul 1>nul
echo %time%
goto loop
ping.exe 2912k
误差评定: 一般
优点: 代码构造简单，时间越长误差越小，精确度较高(50ms)
缺点: 内存占用高
3.call
内存使用: cmd.exe 1744k [for语句方案]@echo off
:loop
echo %time%
call :delay 1000
echo %time%
goto loop
:delay
set /a num=num + 1
if %num% geq %1 (set num=) && goto :eof
rem for /l %%i in (1,1,%1) do echo. >nul
goto :eof
cmd.exe 1740k [set+goto方案]
误差评定: 很高 (受CPU频率影响非常大，几乎无法准确把握全局延迟时间)
优点: 精确度较高
缺点: 不适合需精确把握时间的场合
4.msg
内存使用: cmd.exe 1752k@echo off
:loop
echo %time%
msg %username% /time:20 /w "正在延时，点确定可以取消延时!"
echo %time%
goto loop
msg.exe 2620k
误差评定: 低
优点: 比较稳定，可中途取消延时，代码构造简单
缺点: 内存占用非常大，有窗口弹出(优点？缺点？)
5.vbs
内存使用: cscript.exe 4812k@echo off
echo Wscript.Sleep WScript.Arguments(0) >%tmp%\delay.vbs
:loop
echo %time%
cscript //b //nologo %tmp%\delay.vbs 2000
echo %time%
goto loop
cmd.exe 1708k
误差评定: 很低
优点: 精确度最高，使用更灵活，方便
缺点: 产生临时文件，内存占用多
从Reader向InputStream转换的类(转载）
public class ReaderInputStream extends InputStream {
protected Reader reader;
protected ByteArrayOutputStream byteArrayOut;
protected Writer writer;
protected char[] chars;
protected byte[] buffer;
protected int index, length;
/**
* 带Reader参数构造函数
*
* @param reader - InputStream使用的Reader
*/
public ReaderInputStream(Reader reader) {
this.reader = reader;
byteArrayOut = new ByteArrayOutputStream();
writer = new OutputStreamWriter(byteArrayOut);
chars = new char[1024];
}
/**
* 带Reader和字符编码格式参数的构造函数
*
* @param reader - InputStream使用的Reader
* @param encoding - InputStream使用的字符编码格式.
* @throws 如果字符编码格式不支持,则抛UnsupportedEncodingException异常
*/
public ReaderInputStream(Reader reader, String encoding)
throws UnsupportedEncodingException {
this.reader = reader;
byteArrayOut = new ByteArrayOutputStream();
writer = new OutputStreamWriter(byteArrayOut, encoding);
chars = new char[1024];
}
/**
* @see java.io.InputStream#read()
*/
public int read() throws IOException {
if (index >= length)
fillBuffer();
if (index >= length)
return -1;
return 0xff & buffer[index++];
}
protected void fillBuffer() throws IOException {
if (length < 0)
return;
int numChars = reader.read(chars);
if (numChars < 0) {
length = -1;
} else {
byteArrayOut.reset();
writer.write(chars, 0, numChars);
writer.flush();
buffer = byteArrayOut.toByteArray();
length = buffer.length;
index = 0;
}
}
/**
* @see java.io.InputStream#read(byte[], int, int)
*/
public int read(byte[] data, int off, int len) throws IOException {
if (index >= length)
fillBuffer();
if (index >= length)
return -1;
int amount = Math.min(len, length - index);
System.arraycopy(buffer, index, data, off, amount);
index += amount;
return amount;
}
/**
* @see java.io.InputStream#available()
*/
public int available() throws IOException {
return (index < length) ? length - index :
((length >= 0) && reader.ready()) ? 1 : 0;
}
/**
* @see java.io.InputStream#close()
*/
public void close() throws IOException {
reader.close();
}
}
protected Reader reader;
protected ByteArrayOutputStream byteArrayOut;
protected Writer writer;
protected char[] chars;
protected byte[] buffer;
protected int index, length;
/**
* 带Reader参数构造函数
*
* @param reader - InputStream使用的Reader
*/
public ReaderInputStream(Reader reader) {
this.reader = reader;
byteArrayOut = new ByteArrayOutputStream();
writer = new OutputStreamWriter(byteArrayOut);
chars = new char[1024];
}
/**
* 带Reader和字符编码格式参数的构造函数
*
* @param reader - InputStream使用的Reader
* @param encoding - InputStream使用的字符编码格式.
* @throws 如果字符编码格式不支持,则抛UnsupportedEncodingException异常
*/
public ReaderInputStream(Reader reader, String encoding)
throws UnsupportedEncodingException {
this.reader = reader;
byteArrayOut = new ByteArrayOutputStream();
writer = new OutputStreamWriter(byteArrayOut, encoding);
chars = new char[1024];
}
/**
* @see java.io.InputStream#read()
*/
public int read() throws IOException {
if (index >= length)
fillBuffer();
if (index >= length)
return -1;
return 0xff & buffer[index++];
}
protected void fillBuffer() throws IOException {
if (length < 0)
return;
int numChars = reader.read(chars);
if (numChars < 0) {
length = -1;
} else {
byteArrayOut.reset();
writer.write(chars, 0, numChars);
writer.flush();
buffer = byteArrayOut.toByteArray();
length = buffer.length;
index = 0;
}
}
/**
* @see java.io.InputStream#read(byte[], int, int)
*/
public int read(byte[] data, int off, int len) throws IOException {
if (index >= length)
fillBuffer();
if (index >= length)
return -1;
int amount = Math.min(len, length - index);
System.arraycopy(buffer, index, data, off, amount);
index += amount;
return amount;
}
/**
* @see java.io.InputStream#available()
*/
public int available() throws IOException {
return (index < length) ? length - index :
((length >= 0) && reader.ready()) ? 1 : 0;
}
/**
* @see java.io.InputStream#close()
*/
public void close() throws IOException {
reader.close();
}
}
订阅：
博文 (Atom)
