今天修改了jsf的验证器部分...看到了对于email的验证.....看起来还是有点头大呀.....于是乎翻javadoc....找到了
java.util.regex.Pattern类....挺有意思的...一起分享一下......
java.util.regex
类 Pattern
java.lang.Objectjava.util.regex.Pattern
- 所有已实现的接口:
- Serializable
public final class Pattern
- extends Object
- implements Serializable
正则表达式的编译表示形式。
指定为字符串的正则表达式必须首先被编译为此类的实例。然后,可将得到的模式用于创建 Matcher
对象,依照正则表达式,该对象可以与任意
字符序列
匹配。执行匹配所涉及的所有状态都驻留在匹配器中,所以多个匹配器可以共享同一模式。
因此,典型的调用顺序是
Pattern p = Pattern.compile
("a*b");
Matcher m = p.matcher
("aaaaab");
boolean b = m.matches
();
在仅使用一次正则表达式时,可以方便地通过此类定义 matches
方法。此方法编译表达式并在单个调用中将输入序列与其匹配。语句
boolean b = Pattern.matches("a*b", "aaaaab");
等效于上面的三个语句,尽管对于重复的匹配而言它效率不高,因为它不允许重用已编译的模式。
此类的实例是不可变的,可供多个并发线程安全使用。Matcher
类的实例用于此目的则不安全。 正则表达式的构造摘要
构造 | 匹配 |
---|
|
---|
字符 |
---|
x | 字符 x |
\\ | 反斜线字符 |
\0n | 带有八进制值 0 的字符 n (0 <= n <= 7) |
\0nn | 带有八进制值 0 的字符 nn (0 <= n <= 7) |
\0mnn | 带有八进制值 0 的字符 mnn(0 <= m <= 3、0 <= n <= 7) |
\xhh | 带有十六进制值 0x 的字符 hh |
\uhhhh | 带有十六进制值 0x 的字符 hhhh |
\t | 制表符 ('\u0009') |
\n | 新行(换行)符 ('\u000A') |
\r | 回车符 ('\u000D') |
\f | 换页符 ('\u000C') |
\a | 报警 (bell) 符 ('\u0007') |
\e | 转义符 ('\u001B') |
\cx | 对应于 x 的控制符 |
|
---|
字符类 |
---|
[abc] | a、b 或 c(简单类) |
[^abc] | 任何字符,除了 a、b 或 c(否定) |
[a-zA-Z] | a 到 z 或 A 到 Z,两头的字母包括在内(范围) |
[a-d[m-p]] | a 到 d 或 m 到 p:[a-dm-p](并集) |
[a-z&&[def]] | d、e 或 f(交集) |
[a-z&&[^bc]] | a 到 z,除了 b 和 c:[ad-z](减去) |
[a-z&&[^m-p]] | a 到 z,而非 m 到 p:[a-lq-z](减去) |
|
---|
预定义字符类 |
---|
. | 任何字符(与行结束符可能匹配也可能不匹配) |
\d | 数字:[0-9] |
\D | 非数字: [^0-9] |
\s | 空白字符:[ \t\n\x0B\f\r] |
\S | 非空白字符:[^\s] |
\w | 单词字符:[a-zA-Z_0-9] |
\W | 非单词字符:[^\w] |
|
---|
POSIX 字符类(仅 US-ASCII) |
---|
\p{Lower} | 小写字母字符:[a-z] |
\p{Upper} | 大写字母字符:[A-Z] |
\p{ASCII} | 所有 ASCII:[\x00-\x7F] |
\p{Alpha} | 字母字符:[\p{Lower}\p{Upper}] |
\p{Digit} | 十进制数字:[0-9] |
\p{Alnum} | 字母数字字符:[\p{Alpha}\p{Digit}] |
\p{Punct} | 标点符号:!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ |
\p{Graph} | 可见字符:[\p{Alnum}\p{Punct}] |
\p{Print} | 可打印字符:[\p{Graph}\x20] |
\p{Blank} | 空格或制表符:[ \t] |
\p{Cntrl} | 控制字符:[\x00-\x1F\x7F] |
\p{XDigit} | 十六进制数字:[0-9a-fA-F] |
\p{Space} | 空白字符:[ \t\n\x0B\f\r] |
|
---|
java.lang.Character 类(简单的 java 字符类型) |
---|
\p{javaLowerCase} | 等效于 java.lang.Character.isLowerCase() |
\p{javaUpperCase} | 等效于 java.lang.Character.isUpperCase() |
\p{javaWhitespace} | 等效于 java.lang.Character.isWhitespace() |
\p{javaMirrored} | 等效于 java.lang.Character.isMirrored() |
|
---|
Unicode 块和类别的类 |
---|
\p{InGreek} | Greek 块(简单块)中的字符 |
\p{Lu} | 大写字母(简单类别) |
\p{Sc} | 货币符号 |
\P{InGreek} | 所有字符,Greek 块中的除外(否定) |
[\p{L}&&[^\p{Lu}]] | 所有字母,大写字母除外(减去) |
|
---|
边界匹配器 |
---|
^ | 行的开头 |
$ | 行的结尾 |
\b | 单词边界 |
\B | 非单词边界 |
\A | 输入的开头 |
\G | 上一个匹配的结尾 |
\Z | 输入的结尾,仅用于最后的结束符(如果有的话) |
\z | 输入的结尾 |
|
---|
Greedy 数量词 |
---|
X? | X,一次或一次也没有 |
X* | X,零次或多次 |
X+ | X,一次或多次 |
X{n} | X,恰好 n 次 |
X{n,} | X,至少 n 次 |
X{n,m} | X,至少 n 次,但是不超过 m 次 |
|
---|
Reluctant 数量词 |
---|
X?? | X,一次或一次也没有 |
X*? | X,零次或多次 |
X+? | X,一次或多次 |
X{n}? | X,恰好 n 次 |
X{n,}? | X,至少 n 次 |
X{n,m}? | X,至少 n 次,但是不超过 m 次 |
|
---|
Possessive 数量词 |
---|
X?+ | X,一次或一次也没有 |
X*+ | X,零次或多次 |
X++ | X,一次或多次 |
X{n}+ | X,恰好 n 次 |
X{n,}+ | X,至少 n 次 |
X{n,m}+ | X,至少 n 次,但是不超过 m 次 |
|
---|
Logical 运算符 |
---|
XY | X 后跟 Y |
X|Y | X 或 Y |
(X) | X,作为捕获组 |
|
---|
Back 引用 |
---|
\n | 任何匹配的 nth捕获组 |
|
---|
引用 |
---|
\ | Nothing,但是引用以下字符 |
\Q | Nothing,但是引用所有字符,直到 \E |
\E | Nothing,但是结束从 \Q 开始的引用 |
|
---|
特殊构造(非捕获) |
---|
(?:X) | X,作为非捕获组 |
(?idmsux-idmsux) | Nothing,但是将匹配标志由 on 转为 off |
(?idmsux-idmsux:X) | X,作为带有给定标志 on - off 的非捕获组 |
(?=X) | X,通过零宽度的正 lookahead |
(?!X) | X,通过零宽度的负 lookahead |
(?<=X) | X,通过零宽度的正 lookbehind |
(?<!X) | X,通过零宽度的负 lookbehind |
(?>X) | X,作为独立的非捕获组 |
反斜线、转义和引用
反斜线字符 ('\') 用于引用转义构造,如上表所定义的,同时还用于引用其他将被解释为非转义构造的字符。因此,表达式 \\ 与单个反斜线匹配,而 \{ 与左括号匹配。
在不表示转义构造的任何字母字符前使用反斜线都是错误的;它们是为将来扩展正则表达式语言保留的。可以在非字母字符前使用反斜线,不管该字符是否非转义构造的一部分。
根据 Java Language Specification 的要求,Java 源代码的字符串中的反斜线被解释为 Unicode 转义或其他字符转义。因此必须在字符串字面值中使用两个反斜线,表示正则表达式受到保护,不被 Java 字节码编译器解释。例如,当解释为正则表达式时,字符串字面值 "\b" 与单个退格字符匹配,而 "\\b" 与单词边界匹配。字符串字面值 "\(hello\)" 是非法的,将导致编译时错误;要与字符串 (hello) 匹配,必须使用字符串字面值 "\\(hello\\)"。 字符类
字符类可以出现在其他字符类中,并且可以包含并集运算符(隐式)和交集运算符 (&&)。并集运算符表示至少包含其某个操作数类中所有字符的类。交集运算符表示包含同时位于其两个操作数类中所有字符的类。
字符类运算符的优先级如下所示,按从最高到最低的顺序排列:
1 | 字面值转义 | \x |
---|
2 | 分组 | [...] |
---|
3 | 范围 | a-z |
---|
4 | 并集 | [a-e][i-u] |
---|
5 | 交集 | [a-z&&[aeiou]] |
---|
注意,元字符的不同集合实际上位于字符类的内部,而非字符类的外部。例如,正则表达式 . 在字符类内部就失去了其特殊意义,而表达式 - 变成了形成元字符的范围。 行结束符
行结束符 是一个或两个字符的序列,标记输入字符序列的行结尾。以下代码被识别为行结束符:
- 新行(换行)符 ('\n')、
- 后面紧跟新行符的回车符 ("\r\n")、
- 单独的回车符 ('\r')、
- 下一行字符 ('\u0085')、
- 行分隔符 ('\u2028') 或
- 段落分隔符 ('\u2029)。
如果激活 UNIX_LINES
模式,则新行符是惟一识别的行结束符。
如果未指定 DOTALL
标志,则正则表达式 . 可以与任何字符(行结束符除外)匹配。
默认情况下,正则表达式 ^ 和 $ 忽略行结束符,仅分别与整个输入序列的开头和结尾匹配。如果激活 MULTILINE
模式,则 ^ 在输入的开头和行结束符之后(输入的结尾)才发生匹配。处于 MULTILINE
模式中时,$ 仅在行结束符之前或输入序列的结尾处匹配。 组和捕获
捕获组可以通过从左到右计算其开括号来编号。例如,在表达式 ((A)(B(C))) 中,存在四个这样的组:
1 | ((A)(B(C))) |
---|
2 | \A |
---|
3 | (B(C)) |
---|
4 | (C) |
---|
组零始终代表整个表达式。
之所以这样命名捕获组是因为在匹配中,保存了与这些组匹配的输入序列的每个子序列。捕获的子序列稍后可以通过 Back 引用在表达式中使用,也可以在匹配操作完成后从匹配器检索。
与组关联的捕获输入始终是与组最近匹配的子序列。如果由于量化的缘故再次计算了组,则在第二次计算失败时将保留其以前捕获的值(如果有的话)例如,将字符串 "aba" 与表达式 (a(b)?)+ 相匹配,会将第二组设置为 "b"。在每个匹配的开头,所有捕获的输入都会被丢弃。
以 (?) 开头的组是纯的非捕获 组,它不捕获文本,也不针对组合计进行计数。
Unicode 支持
此类符合 Unicode Technical Standard #18:Unicode Regular Expression Guidelines 第 1 级和 RL2.1 Canonical Equivalents。
Java 源代码中的 Unicode 转义序列(如 \u2014)是按照 Java Language Specification 的 第 3.3 节中的描述处理的。这样的转义序列还可以由正则表达式分析器直接实现,以便在从文件或键盘击键读取的表达式中使用 Unicode 转义。因此,可以将不相等的字符串 "\u2014" 和 "\\u2014" 编译为相同的模式,从而与带有十六进制值 0x2014 的字符匹配。 与 Perl 中一样,Unicode 块和类别是使用 \p 和 \P 构造编写的。如果输入具有属性 prop,则与 \p{prop} 匹配,而输入具有该属性时与 \P{prop} 不匹配。块使用前缀 In 指定,与在 InMongolian 中一样。可以使用可选前缀 Is 指定类别:\p{L} 和 \p{IsL} 都表示 Unicode 字母的类别。块和类别在字符类的内部和外部都可以使用。
受支持的类别是由 Character
类指定版本中的 The Unicode Standard 的类别。类别名称是在 Standard 中定义的,即标准又丰富。Pattern
所支持的块名称是 UnicodeBlock.forName
所接受和定义的有效块名称。 行为类似 java.lang.Character boolean 是 methodname 方法(废弃的类别除外)的类别,可以通过相同的 \p{prop} 语法来提供,其中指定的属性具有名称 javamethodname。
与 Perl 5 相比较
Pattern
引擎用有序替换项执行传统上基于 NFA 的匹配,与 Perl 5 中进行的相同。
此类不支持 Perl 构造:
此类支持但 Perl 不支持的构造:
与 Perl 的显著不同点是:
在 Perl 中,\1 到 \9 始终被解释为 Back 引用;如果至少存在多个子表达式,则大于 9 的反斜线转义数按 Back 引用对待,否则在可能的情况下,它将被解释为八进制转义。在此类中,八进制转义必须始终以零开头。在此类中,\1 到 \9 始终被解释为 Back 引用,较大的数被接受为 Back 引用,如果在正则表达式中至少存在多个子表达式的话;否则,分析器将删除数字,直到该数小于或等于组的现有数或者其为一个数字。
Perl 使用 g 标志请求恢复最后匹配丢失的匹配。此功能是由 Matcher
类显式提供的:重复执行 find
方法调用可以恢复丢失的最后匹配,除非匹配器被重置。
在 Perl 中,位于表达式顶级的嵌入式标记对整个表达式都有影响。在此类中,嵌入式标志始终在它们出现的时候才起作用,不管它们位于顶级还是组中;在后一种情况下,与在 Perl 中类似,标志在组的结尾处还原。
Perl 允许错误匹配构造,如在表达式 *a 中,以及不匹配的括号,如在在表达式 abc] 中,并将其作为字面值对待。此类还接受不匹配的括号,但对 +、? 和 * 不匹配元字符有严格限制;如果遇到它们,则抛出 PatternSyntaxException
。
有关正则表达式构造行为更准确的描述,请参见《Mastering Regular Expressions, 2nd Edition》,该书由 Jeffrey E. F. Friedl、O'Reilly 和 Associates 合著,于 2002 年出版。
- 从以下版本开始:
- 1.4
- 另请参见:
String.split(String, int)
, String.split(String)
, 序列化表格
这样下来检验email的代码也是相当简单呀....
boolean b = Pattern.matches("^\\w+@\\w+(
\\.\\w+)+", email);
posted @
2006-11-18 22:38 Stefanie 阅读(5918) |
评论 (1) |
编辑 收藏
P2P网络的拓扑结构
拓扑结构是指分布式系统中各个计算单元之间的物理或逻辑的互联关系,结点之间的拓扑结构一直是确定系统类型的重要依据。目前互联网络中广泛使用集中式、层次式等拓扑结构。Internet本身是世界上最大的非集中式的互联网络,但是九十年代所建立的一些网络应用系统却是完全的集中式的系统,许多Web应用都是运行在集中式的服务器系统上。集中式拓扑结构系统目前面临着过量存储负载、DOS(Denial of Service,拒绝服务)攻击,网络带宽限制等一些难以解决的问题。Peer-to-Peer (简称P2P) 系统主要采用非集中式的拓扑结构,一般来说不存在上述这些难题。根据结构关系可以将P2P系统细分为四种拓扑形式:
-
中心化拓扑(Centralized Topology);
-
全分布式非结构化拓扑(Decentralized Unstructured Topology);
-
全分布式结构化拓扑(Decentralized Structured Topology,也称作DHT网络);
-
半分布式拓扑(Partially Decentralized Topology)。
其中,中心化拓扑最大的优点是维护简单,资源发现效率高。由于资源的发现依赖中心化的目录系统,发现算法灵活高效并能够实现复杂查询。最大的问题与传统客户机/服务器结构类似,容易造成单点故障,访问的“热点”现象和版权纠纷等相关问题,这是第一代P2P网络采用的结构模式,经典案例就是著名的MP3共享软件Napster[1].
Napster是最早出现的P2P系统之一,并在短期内迅速成长起来。它实质上并非是纯粹的P2P系统,而是通过一个中央索引服务器保存所有Napster用户上传的音乐文件索引和存放位置的信息。它的工作原理如图1所示。当某个用户需要某个音乐文件时,首先连接到Napster中央索引服务器,在服务器上进行检索,服务器返回存有该文件的用户信息,再由请求者直接连到文件的所有者传输文件。Napster首先实现了文件查询与文件传输的分离,有效地节省了中央服务器的带宽消耗,减少了系统的文件传输延时。
图1 Napster的拓扑结构
然而,这种对等网络模型存在以下这些问题:
- 中央索引服务器的瘫痪容易导致整个网络的崩溃,因此可靠性和安全性较低。
- 随着网络规模的扩大,对中央索引服务器进行维护和更新的费用将急剧增加,所需成本较高。
- 中央索引服务器的存在常引起版权问题上的纠纷,服务提供商容易被追究法律责任。
综合上述优缺点,对小型网络而言,中心化拓扑模型在管理和控制方面占一定优势。但鉴于其存在的上述缺陷,该模型并不适合大型网络应用。
全分布式非结构化拓扑的P2P网络是在重叠网络(Overlay Network)(见标注1)采用了随机图的组织方式,结点度数服从Power-law规律(幂次法则)[2],从而能够较快发现目的结点,面对网络的动态变化体现了较好的容错能力,因此具有较好的可用性。同时可以支持复杂查询,如带有规则表达式的多关键词查询,模糊查询等,采用这种拓扑结构最典型的案例便是Gnutella(音译:纽特拉)。准确地说,Gnutella不是特指某一款软件,而是指遵守Gnutella协议[3]的网络以及客户端软件的统称。目前基于Gnutella网络的客户端软件非常多,著名的有Shareaza、LimeWire和BearShare等。
图2Gnutella的拓扑结构和文件检索方法
Gnutella和Napster最大的区别在于Gnutella是更加纯粹的P2P系统,因为它没有中央索引服务器,每台机器在Gnutella网络中是真正的对等关系,既是客户机同时又是服务器,所以被称为对等机(Servent,Server+Client的组合)。在文件检索方面,它与Napster也不相同。在Gnutella网络的发展初期,它主要采用基于完全随机图的Flooding搜索算法。图2 显示了Flooding的工作流程:当一台计算机要下载一个文件,它首先以文件名或者关键字生成一个查询,并把这个查询发送给与它相连的所有计算机,这些计算机如果存在这个文件,则与查询的机器建立连接,如果不存在这个文件,则继续在自己相邻的计算机之间转发这个查询,直到找到文件为止。为了控制搜索消息不至于永远这样传递下去,一般通过TTL (Time To Live)的减值来控制查询的深度。
但是,随着联网节点的不断增多,网络规模不断扩大,通过这种Flooding方式定位对等点的方法将造成网络流量急剧增加,从而导致网络中部分低带宽节点因网络资源过载而失效。所以在初期的Gnutella网络中,存在比较严重的分区,断链现象。也就是说,一个查询访问只能在网络的很小一部分进行,因此网络的可扩展性不好。所以,后来许多研究人员在Flooding的基础上作了许多改进,例如采用Random work [4]、Dynamic Query[5]等方法。
由于非结构化网络将重叠网络认为是一个完全随机图,结点之间的链路没有遵循某些预先定义的拓扑来构建。这些系统一般不提供性能保证,但容错性好,支持复杂的查询,并受结点频繁加入和退出系统的影响小。但是查询的结果可能不完全,查询速度较慢,采用Flooding查询的系统对网络带宽的消耗非常大,并由此带来可扩展性差等问题。
全分布式结构化拓扑的P2P网络主要是采用分布式散列表(Distributed Hash Table, 简写成DHT)技术来组织网络中的结点。DHT是一个由广域范围大量结点共同维护的巨大散列表。散列表被分割成不连续的块,每个结点被分配给一个属于自己的散列块,并成为这个散列块的管理者。通过加密散列函数,一个对象的名字或关键词被映射为128位或160位的散列值。分布式散列表起源于SDDS(Scalable Distribute Data Structures)[6]研究,Gribble等实现了一个高度可扩展,容错的SDDS集群。DHT类结构能够自适应结点的动态加入/退出,有着良好的可扩展性、鲁棒性、结点ID分配的均匀性和自组织能力。由于重叠网络采用了确定性拓扑结构,DHT可以提供精确的发现。只要目的结点存在于网络中DHT总能发现它,发现的准确性得到了保证,最经典的案例是Tapestry,Pastry,Chord和CAN。
Tapestry [7]提供了一个分布式容错查找和路由基础平台,在此平台基础之上,可以开发各种P2P应用(OceanStore[8]即是此平台上的一个应用)。Tapestry的思想来源于Plaxton。在Plaxton中,结点使用自己所知道的邻近结点表,按照目的ID来逐步传递消息。Tapestry基于Plaxton的思想,加入了容错机制,从而可适应P2P的动态变化的特点。OceanStore是以Tapestry为路由和查找基础设施的P2P平台。它是一个适合于全球数据存储的P2P应用系统。任何用户均可以加入OceanStore系统,或者共享自己的存储空间,或者使用该系统中的资源。通过使用复制和缓存技术,OceanStore可提高查找的效率。最近,Tapestry为适应P2P网络的动态特性,作了很多改进,增加了额外的机制实现了网络的软状态(soft state),并提供了自组织、鲁棒性、可扩展性和动态适应性,当网络高负载且有失效结点时候性能有限降低,消除了对全局信息的依赖、根结点易失效和弹性差的问题。
Pastry 是微软研究院提出的可扩展的分布式对象定位和路由协议,可用于构建大规模的P2P系统。如图3 所示,在Pastry中,每个结点分配一个128位的结点标识符号(nodeID) ,所有的结点标识符形成了一个环形的nodeID空间,范围从0到2128 - 1 ,结点加入系统时通过散列结点IP地址在128位nodeID空间中随机分配。网络结点的加入与退出,资源查询的过程可以参考文献[9]。
图3Pastry的消息路由
Chord [10]项目诞生于美国的麻省理工学院。它的目标是提供一个适合于P2P环境的分布式资源发现服务,它通过使用DHT技术使得发现指定对象只需要维护O(logN)长度的路由表。在DHT技术中,网络结点按照一定的方式分配一个唯一结点标识符(Node ID) ,资源对象通过散列运算产生一个唯一的资源标识符(Object ID) ,且该资源将存储在结点ID与之相等或者相近的结点上。需要查找该资源时,采用同样的方法可定位到存储该资源的结点。因此,Chord的主要贡献是提出了一个分布式查找协议,该协议可将指定的关键字(Key) 映射到对应的结点(Node) 。从算法来看,Chord是相容散列算法的变体。
图4 Chord的拓扑形状
CAN(Content Addressable Networks)[11] 项目采用多维的标识符空间来实现分布式散列算法。CAN将所有结点映射到一个n维的笛卡尔空间中,并为每个结点尽可能均匀的分配一块区域。CAN采用的散列函数通过对(key, value) 对中的key进行散列运算,得到笛卡尔空间中的一个点,并将(key, value) 对存储在拥有该点所在区域的结点内。CAN采用的路由算法相当直接和简单,知道目标点的坐标后,就将请求传给当前结点四邻中坐标最接近目标点的结点。CAN是一个具有良好可扩展性的系统,给定N个结点,系统维数为d,则路由路径长度为O(n1/d) ,每结点维护的路由表信息和网络规模无关为O(d) 。
上述四种基于DHT的P2P系统的性能比较可以参照[12]。DHT这类结构最大的问题是DHT的维护机制较为复杂,尤其是结点频繁加入退出造成的网络波动(Churn)会极大增加DHT的维护代价。DHT所面临的另外一个问题是DHT仅支持精确关键词匹配查询,无法支持内容/语义等复杂查询。
半分布式拓扑结构(有的文献亦称作混杂模式,英文表达为Hybrid Structure)吸取了中心化结构和全分布式非结构化拓扑的优点,选择性能较高(处理、存储、带宽等方面性能)的结点作为超级结点(英文表达为SuperNodes或者Hubs),在各个超级结点上存储了系统中其他部分结点的信息,发现算法仅在超级结点之间转发,超级结点再将查询请求转发给适当的叶子结点。半分布式结构也是一个层次式结构,超级结点之间构成一个高速转发层,超级结点和所负责的普通结点构成若干层次。采用这种结构的最典型的案例就是KaZaa。
图5 半分布式拓扑结构(网络中包含Super Node)
KaZaa是当前世界最流行的几款P2P文件共享软件之一。根据CA公司统计,全球KaZaa的下载量超过2.5亿次。使用KaZaa软件进行文件传输消耗了互联网40%的带宽。之所以它如此的成功,是因为它结合了Napster和Gnutella共同的优点。从结构上来说,它使用了Gnutella的全分布式的结构,这样可以是系统更好的扩展,因为它无需中央索引服务器存储文件名,它是自动的把性能好的机器成为SuperNode,它存储着离它最近的叶子节点的文件信息,这些SuperNode,再连通起来形成一个Overlay Network. 由于SuperNode的索引功能,使搜索效率大大提高。
图6 KaZaa的软件界面
半分布式结构的优点是性能、可扩展性较好,较容易管理,但对超级点依赖性大,易于受到攻击,容错性也受到影响。
在实际应用中,每种拓扑结构的P2P网络都有其优缺点,下表从可扩展性、可靠性、可维护性、发现算法的效率、复杂查询等方面比较了这四种拓扑结构的综合性能。
比较标准/拓扑结构
|
中心化拓扑
|
全分布式非结构化拓扑
|
全分布式结构化拓扑
|
半分布式拓扑
|
可扩展性
|
差
|
差
|
好
|
中
|
可靠性
|
差
|
好
|
好
|
中
|
可维护性
|
最好
|
最好
|
好
|
中
|
发现算法效率
|
最高
|
中
|
高
|
中
|
复杂查询
|
支持
|
支持
|
不支持
|
支持
|
我还是比较看好chord...虽然目前还有不少问题没有解决....
顺便附上一篇经典的chord论文: Chord: A Scalable Peertopeer Lookup Service for Internet Applications
http://www.blogjava.net/Files/heiyuchuanxia/chord_sigcomm.rar
posted @
2006-11-15 15:28 Stefanie 阅读(3447) |
评论 (0) |
编辑 收藏
摘要: The Summery of OWL-S 1.2
OWL-S is an ontology, within the OWL-based framework of the Semantic Web, for describing Web services.
This documen...
阅读全文
posted @
2006-11-12 14:00 Stefanie 阅读(680) |
评论 (1) |
编辑 收藏
最近的程序中总是出现写奇怪的问题....于是乎就查了一点相关的资料....找到了这样一片相关的文章....感觉收获挺多了..... 分享分享.......
关于Java 初始化,有多文章都用了很大篇幅的介绍。经典的<<Thinking in java>>更是用了专门的一章来介绍Java初始化。但在大量有代码实例后面,感觉上仍然没有真正深入到初始化的本质。
本文以作者对JVM的理解和自己的经验,对Java的初始化做一个比深入的说明,由于作者有水平限制,以及JDK各实现版本的变化,可能仍然有不少错误和缺点。欢迎行家高手赐教。
要深入了解Java初始化,我们无法知道从程序流程上知道JVM是按什么顺序来执行的。了解JVM的执行机制和堆栈跟踪是有效的手段。可惜的是,到目前为止。JDK1。4和JDK1。5在javap功能上却仍然存在着BUG。所以有些过程我无法用实际的结果向你证明两种相反的情况。
<<Thinking in java>>(第三版)在第四章一开始的时候,这样来描述Java的初始化工作:
以下译文原文:
可以这样认为,每个类都有一个名为Initialize()的方法,这个名字就暗示了它得在使用之前调用,不幸的是,这么做的话,用户就得记住要调用这个方法,java类库的设计者们可以通过一种被称为构造函数的特殊方法,来保证每个对象都能得到被始化.如果类有构造函数,那么java就会在对象刚刚创建,用户还来不及得到的时候,自动调用那个构造函数,这样初始化就有保障了。
我不知道原作者的描述和译者的理解之间有多大的差异,结合全章,我没有发现两个最关键的字"<clinit>"和"<init>"。至少说明原作者和译者并没有真正说明JVM在初始化时做了什么,或者说并不了解JVM的初始化内幕,要不然明明有这两个方法,却为什么要认为有一个事实上并不存在的"Initialize()"方法呢?
"<clinit>"和"<init>"方法在哪里?这两个方法是实际存在而你又找不到的方法,也许正是这样才使得一些大师都犯晕。加上jdk实现上的一些BUG,如果没有深入了解,真的让人摸不着北。
现在科学体系有一个奇怪的现象,那么庞大的体系最初都是建立在一个假设的基础是,假设1是正确的,由此推导出2,再继续推导出10000000000。可惜的是太多的人根本不在乎2-100000000000这样的体系都是建立在假设1是正确的基础上的。我并不会用“可以这样认为”这样的假设,我要确实证明"<clinit>"和"<init>"方法是真真实实的存在的:
package debug;
public class MyTest{
static int i = 100/0;
public static void main(String[] args){
Ssytem.out.println("Hello,World!");
}
}
执行一下看看,这是jdk1.5的输出:
java.lang.ExceptionInInitializerError
Caused by: java.lang.ArithmeticException: / by zero
at debug.MyTest.(Test.java:3)
Exception in thread "main"
请注意,和其它方法调用时产生的异常一样,异常被定位于debug.MyTest的<clinit>.
再来看:
package debug;
public class Test {
Test(){
int i = 100 / 0;
}
public static void main(String[] args) {
new Test();
}
}
jdk1.5输入:
Exception in thread "main" java.lang.ArithmeticException: / by zero
at debug.Test.<init>(Test.java:4)
at debug.Test.main(Test.java:7)
JVM并没有把异常定位在Test()构造方法中,而是在debug.Test.<init>。 当我们看到了这两个方法以后,我们再来详细讨论这两个“内置初始化方法”(我并不喜欢生造一些
非标准的术语,但我确实不知道如何规范地称呼他们)。
内置初始化方法是JVM在内部专门用于初始化的特有方法,而不是提供给程序员调用的方法,事实上“<>”这样的语法在源程序中你连编译都无法通过。这就说明,初始化是由JVM控制而不是让程序员来控制的。
类初始化方法:<clinit>
我没有从任何地方了解到<clinit>的cl是不是class的简写,但这个方法确实是用来对“类”进行初
始化的。换句话说它是用来初始化static上下文的。
在类装载(load)时,JVM会调用内置的<clinit>方法对类成员和静态初始化块进行初始化调用。它们的顺序按照源文件的原文顺序。
我们稍微增加两行static语句:
package debug;
public class Test {
static int x = 0;
static String s = "123";
static {
String s1 = "456";
if(1==1)
throw new RuntimeException();
}
public static void main(String[] args) {
new Test();
}
}
然后进行反编译:
javap -c debug.Test
Compiled from "Test.java"
public class debug.Test extends java.lang.Object{
static int x;
static java.lang.String s;
public debug.Test();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."":()V
4: return
public static void main(java.lang.String[]);
Code:
0: new #2; //class debug/Test
3: dup
4: invokespecial #3; //Method "":()V
7: pop
8: return
static {};
Code:
0: iconst_0
1: putstatic #4; //Field x:I
4: ldc #5; //String 123
6: putstatic #6; //Field s:Ljava/lang/String;
9: ldc #7; //String 456
11: astore_0
12: new #8; //class java/lang/RuntimeException
15: dup
16: invokespecial #9; //Method java/lang/RuntimeException."":()V
19: athrow
我们可以看到,类初始化正是按照源文件中定义的原文顺序进行。先是声明 static int x;
static java.lang.String s;
然后对int x和String s进行赋值:
0: iconst_0
1: putstatic #4; //Field x:I
4: ldc #5; //String 123
6: putstatic #6; //Field s:Ljava/lang/String;
执行初始化块的String s1 = "456";生成一个RuntimeException抛
9: ldc #7; //String 456
11: astore_0
12: new #8; //class java/lang/RuntimeException
15: dup
16: invokespecial #9; //Method java/lang/RuntimeException."":()V
19: athrow
要明白的是,"<clinit>"方法不仅是类初始化方法,而且也是接口初始化方法。并不是所以接口
的属性都是内联的,只有直接赋常量值的接口常量才会内联。而
[public static final] double d = Math.random()*100;
这样的表达式是需要计算的,在接口中就要由"<clinit>"方法来初始化。
下面我们再来看看实例初始化方法"<init>"
"<init>"用于对象创建时对对象进行初始化,当在HEAP中创建对象时,一旦在HEAP分配了空间。最先就会调用"<init>"方法。这个方法包括实例变量的赋值(声明不在其中)和初始化块,以及构造方法调用。如果有多个重载的构造方法,每个构造方法都会有一个对应的"<init>"方法。构造方法隐式或显示调用父类的构造方法前,总是先执行实例变量初始化和初始化块.同样,实例变量和初始化块的顺序也是按源文件的原文顺序执行,构造方法中的代码在最后执行:
package debug;
public class Test {
int x = 0;
String s = "123";
{
String s1 = "456";
//if(1==1)
//throw new RuntimeException();
}
public Test(){
String ss = "789";
}
public static void main(String[] args) {
new Test();
}
}
javap -c debug.Test的结果:
Compiled from "Test.java"
public class debug.Test extends java.lang.Object{
int x;
java.lang.String s;
public debug.Test();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."":()V
4: aload_0
5: iconst_0
6: putfield #2; //Field x:I
9: aload_0
10: ldc #3; //String 123
12: putfield #4; //Field s:Ljava/lang/String;
15: ldc #5; //String 456
17: astore_1
18: ldc #6; //String 789
20: astore_1
21: return
public static void main(java.lang.String[]);
Code:
0: new #7; //class debug/Test
3: dup
4: invokespecial #8; //Method "":()V
7: pop
8: return
}
如果在同一个类中,一个构造方法调用了另一个构造方法,那么对应的"<init>"方法就会调用另一
个"<init>",但是实例变量和初始化块会被忽略,否则它们就会被多次执行。
package debug;
public class Test {
String s1 = rt("s1");
String s2 = "s2";
public Test(){
s1 = "s1";
}
public Test(String s){
this();
if(1==1) throw new Runtime();
}
String rt(String s){
return s;
}
public static void main(String[] args) {
new Test("");
}
}
反编译的结果:
Compiled from "Test.java"
public class debug.Test extends java.lang.Object{
java.lang.String s1;
java.lang.String s2;
public debug.Test();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."":()V
4: aload_0
5: aload_0
6: ldc #2; //String s1
8: invokevirtual #3; //Method rt:(Ljava/lang/String;)Ljava/lang/String;
11: putfield #4; //Field s1:Ljava/lang/String;
14: aload_0
15: ldc #5; //String s2
17: putfield #6; //Field s2:Ljava/lang/String;
20: aload_0
21: ldc #2; //String s1
23: putfield #4; //Field s1:Ljava/lang/String;
26: return
public debug.Test(java.lang.String);
Code:
0: aload_0
1: invokespecial #7; //Method "":()V
4: new #8; //class java/lang/RuntimeException
7: dup
8: invokespecial #9; //Method java/lang/RuntimeException."":()V
11: athrow
java.lang.String rt(java.lang.String);
Code:
0: aload_1
1: areturn
public static void main(java.lang.String[]);
Code:
0: new #10; //class debug/Test
3: dup
4: ldc #11; //String
6: invokespecial #12; //Method "":(Ljava/lang/String;)V
9: pop
10: return
}
我们看到,由于Test(String s)调用了Test();所以"<init>":(Ljava/lang/String;)V不再对
实例变量和初始化块进次初始化:
public debug.Test(java.lang.String);
Code:
0: aload_0
1: invokespecial #7; //Method "":()V
4: new #8; //class java/lang/RuntimeException
7: dup
8: invokespecial #9; //Method java/lang/RuntimeException."":()V
11: athrow
而如果两个构造方法是相互独立的,则每个构造方法调用前都会执行实例变量和初始化块的调用:
package debug;
public class Test {
String s1 = rt("s1");
String s2 = "s2";
{
String s3 = "s3";
}
public Test() {
s1 = "s1";
}
public Test(String s) {
if (1 == 1)
throw new RuntimeException();
}
String rt(String s) {
return s;
}
public static void main(String[] args) {
new Test("");
}
}
反编译的结果:
Compiled from "Test.java"
public class debug.Test extends java.lang.Object{
java.lang.String s1;
java.lang.String s2;
public debug.Test();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."":()V
4: aload_0
5: aload_0
6: ldc #2; //String s1
8: invokevirtual #3; //Method rt:(Ljava/lang/String;)Ljava/lang/String;
11: putfield #4; //Field s1:Ljava/lang/String;
14: aload_0
15: ldc #5; //String s2
17: putfield #6; //Field s2:Ljava/lang/String;
20: ldc #7; //String s3
22: astore_1
23: aload_0
24: ldc #2; //String s1
26: putfield #4; //Field s1:Ljava/lang/String;
29: return
public debug.Test(java.lang.String);
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."":()V
4: aload_0
5: aload_0
6: ldc #2; //String s1
8: invokevirtual #3; //Method rt:(Ljava/lang/String;)Ljava/lang/String;
11: putfield #4; //Field s1:Ljava/lang/String;
14: aload_0
15: ldc #5; //String s2
17: putfield #6; //Field s2:Ljava/lang/String;
20: ldc #7; //String s3
22: astore_2
23: new #8; //class java/lang/RuntimeException
26: dup
27: invokespecial #9; //Method java/lang/RuntimeException."":()V
30: athrow
java.lang.String rt(java.lang.String);
Code:
0: aload_1
1: areturn
public static void main(java.lang.String[]);
Code:
0: new #10; //class debug/Test
3: dup
4: ldc #11; //String
6: invokespecial #12; //Method "":(Ljava/lang/String;)V
9: pop
10: return
}
明白了上面这些知识,我们来做一个小测试吧:
public class Test2 extends Test1{
{
System.out.print("1");
}
Test2(){
System.out.print("2");
}
static{
System.out.print("3");
}
{
System.out.print("4");
}
public static void main(String[] args) {
new Test2();
}
}
class Test1 {
Test1(){
System.out.print("5");
}
static{
System.out.print("6");
}
}
试试看能清楚打印的顺序吗?如果没有new Test2()将打印什么?
作者:axman 专栏:http://blog.csdn.net/axman/
posted @
2006-11-05 14:43 Stefanie 阅读(377) |
评论 (0) |
编辑 收藏
这两天上课....老师总是提到蚁群算法....听起来似乎很有意思......找到一篇简介.....放在这里有兴趣的朋友...参考一下........
程序开始运行,蚂蚁们开始从窝里出动了,寻找食物;他们会顺着屏幕爬满整个画面,直到找到食物再返回窝。
其中,‘F’点表示食物,‘H’表示窝,白色块表示障碍物,‘+’就是蚂蚁了。
预期的结果:
各个蚂蚁在没有事先告诉他们食物在什么地方的前提下开始寻找食物。当一只找到食物以后,它会向环境释放一种信息素,吸引其他的蚂蚁过来,这样越来越多的蚂蚁会找到食物!有些蚂蚁并没有象其它蚂蚁一样总重复同样的路,他们会另辟蹊径,如果令开辟的道路比原来的其他道路更短,那么,渐渐,更多的蚂蚁被吸引到这条较短的路上来。最后,经过一段时间运行,可能会出现一条最短的路径被大多数蚂蚁重复着。
原理:
为什么小小的蚂蚁能够找到食物?他们具有智能么?设想,如果我们要为蚂蚁设计一个人工智能的程序,那么这个程序要多么复杂呢?首先,你要让蚂蚁能够避开障碍物,就必须根据适当的地形给它编进指令让他们能够巧妙的避开障碍物,其次,要让蚂蚁找到食物,就需要让他们遍历空间上的所有点;再次,如果要让蚂蚁找到最短的路径,那么需要计算所有可能的路径并且比较它们的大小,而且更重要的是,你要小心翼翼的编程,因为程序的错误也许会让你前功尽弃。这是多么不可思议的程序!太复杂了,恐怕没人能够完成这样繁琐冗余的程序。
然而,事实并没有你想得那么复杂,上面这个程序每个蚂蚁的核心程序编码不过100多行!为什么这么简单的程序会让蚂蚁干这样复杂的事情?答案是:简单规则的涌现。事实上,每只蚂蚁并不是像我们想象的需要知道整个世界的信息,他们其实只关心很小范围内的眼前信息,而且根据这些局部信息利用几条简单的规则进行决策,这样,在蚁群这个集体里,复杂性的行为就会凸现出来。这就是人工生命、复杂性科学解释的规律!那么,这些简单规则是什么呢?下面详细说明:
1、范围:
蚂蚁观察到的范围是一个方格世界,蚂蚁有一个参数为速度半径(一般是3),那么它能观察到的范围就是3*3个方格世界,并且能移动的距离也在这个范围之内。
2、环境:
蚂蚁所在的环境是一个虚拟的世界,其中有障碍物,有别的蚂蚁,还有信息素,信息素有两种,一种是找到食物的蚂蚁洒下的食物信息素,一种是找到窝的蚂蚁洒下的窝的信息素。每个蚂蚁都仅仅能感知它范围内的环境信息。环境以一定的速率让信息素消失。
3、觅食规则:
在每只蚂蚁能感知的范围内寻找是否有食物,如果有就直接过去。否则看是否有信息素,并且比较在能感知的范围内哪一点的信息素最多,这样,它就朝信息素多的地方走,并且每只蚂蚁多会以小概率犯错误,从而并不是往信息素最多的点移动。蚂蚁找窝的规则和上面一样,只不过它对窝的信息素做出反应,而对食物信息素没反应。
4、移动规则:
每只蚂蚁都朝向信息素最多的方向移,并且,当周围没有信息素指引的时候,蚂蚁会按照自己原来运动的方向惯性的运动下去,并且,在运动的方向有一个随机的小的扰动。为了防止蚂蚁原地转圈,它会记住最近刚走过了哪些点,如果发现要走的下一点已经在最近走过了,它就会尽量避开。
5、避障规则:
如果蚂蚁要移动的方向有障碍物挡住,它会随机的选择另一个方向,并且有信息素指引的话,它会按照觅食的规则行为。
7、播撒信息素规则:
每只蚂蚁在刚找到食物或者窝的时候撒发的信息素最多,并随着它走远的距离,播撒的信息素越来越少。
根据这几条规则,蚂蚁之间并没有直接的关系,但是每只蚂蚁都和环境发生交互,而通过信息素这个纽带,实际上把各个蚂蚁之间关联起来了。比如,当一只蚂蚁找到了食物,它并没有直接告诉其它蚂蚁这儿有食物,而是向环境播撒信息素,当其它的蚂蚁经过它附近的时候,就会感觉到信息素的存在,进而根据信息素的指引找到了食物。
问题:
说了这么多,蚂蚁究竟是怎么找到食物的呢?
在没有蚂蚁找到食物的时候,环境没有有用的信息素,那么蚂蚁为什么会相对有效的找到食物呢?这要归功于蚂蚁的移动规则,尤其是在没有信息素时候的移动规则。首先,它要能尽量保持某种惯性,这样使得蚂蚁尽量向前方移动(开始,这个前方是随机固定的一个方向),而不是原地无谓的打转或者震动;其次,蚂蚁要有一定的随机性,虽然有了固定的方向,但它也不能像粒子一样直线运动下去,而是有一个随机的干扰。这样就使得蚂蚁运动起来具有了一定的目的性,尽量保持原来的方向,但又有新的试探,尤其当碰到障碍物的时候它会立即改变方向,这可以看成一种选择的过程,也就是环境的障碍物让蚂蚁的某个方向正确,而其他方向则不对。这就解释了为什么单个蚂蚁在复杂的诸如迷宫的地图中仍然能找到隐蔽得很好的食物。
当然,在有一只蚂蚁找到了食物的时候,其他蚂蚁会沿着信息素很快找到食物的。
蚂蚁如何找到最短路径的?这一是要归功于信息素,另外要归功于环境,具体说是计算机时钟。信息素多的地方显然经过这里的蚂蚁会多,因而会有更多的蚂蚁聚集过来。假设有两条路从窝通向食物,开始的时候,走这两条路的蚂蚁数量同样多(或者较长的路上蚂蚁多,这也无关紧要)。当蚂蚁沿着一条路到达终点以后会马上返回来,这样,短的路蚂蚁来回一次的时间就短,这也意味着重复的频率就快,因而在单位时间里走过的蚂蚁数目就多,洒下的信息素自然也会多,自然会有更多的蚂蚁被吸引过来,从而洒下更多的信息素……;而长的路正相反,因此,越来越多地蚂蚁聚集到较短的路径上来,最短的路径就近似找到了。也许有人会问局部最短路径和全局最短路的问题,实际上蚂蚁逐渐接近全局最短路的,为什么呢?这源于蚂蚁会犯错误,也就是它会按照一定的概率不往信息素高的地方走而另辟蹊径,这可以理解为一种创新,这种创新如果能缩短路途,那么根据刚才叙述的原理,更多的蚂蚁会被吸引过来。
引申
跟着蚂蚁的踪迹,你找到了什么?通过上面的原理叙述和实际操作,我们不难发现蚂蚁之所以具有智能行为,完全归功于它的简单行为规则,而这些规则综合起来具有下面两个方面的特点:
1、多样性
2、正反馈
多样性保证了蚂蚁在觅食的时候不置走进死胡同而无限循环,正反馈机制则保证了相对优良的信息能够被保存下来。我们可以把多样性看成是一种创造能力,而正反馈是一种学习强化能力。正反馈的力量也可以比喻成权威的意见,而多样性是打破权威体现的创造性,正是这两点小心翼翼的巧妙结合才使得智能行为涌现出来了。
引申来讲,大自然的进化,社会的进步、人类的创新实际上都离不开这两样东西,多样性保证了系统的创新能力,正反馈保证了优良特性能够得到强化,两者要恰到好处的结合。如果多样性过剩,也就是系统过于活跃,这相当于蚂蚁会过多的随机运动,它就会陷入混沌状态;而相反,多样性不够,正反馈机制过强,那么系统就好比一潭死水。这在蚁群中来讲就表现为,蚂蚁的行为过于僵硬,当环境变化了,蚂蚁群仍然不能适当的调整。
既然复杂性、智能行为是根据底层规则涌现的,既然底层规则具有多样性和正反馈特点,那么也许你会问这些规则是哪里来的?多样性和正反馈又是哪里来的?我本人的意见:规则来源于大自然的进化。而大自然的进化根据刚才讲的也体现为多样性和正反馈的巧妙结合。而这样的巧妙结合又是为什么呢?为什么在你眼前呈现的世界是如此栩栩如生呢?答案在于环境造就了这一切,之所以你看到栩栩如生的世界,是因为那些不能够适应环境的多样性与正反馈的结合都已经死掉了,被环境淘汰了!
参数说明:
最大信息素:蚂蚁在一开始拥有的信息素总量,越大表示程序在较长一段时间能够存在信息素。信息素消减的速度:随着时间的流逝,已经存在于世界上的信息素会消减,这个数值越大,那么消减的越快。
错误概率表示这个蚂蚁不往信息素最大的区域走的概率,越大则表示这个蚂蚁越有创新性。
速度半径表示蚂蚁一次能走的最大长度,也表示这个蚂蚁的感知范围。
记忆能力表示蚂蚁能记住多少个刚刚走过点的坐标,这个值避免了蚂蚁在本地打转,停滞不前。而这个值越大那么整个系统运行速度就慢,越小则蚂蚁越容易原地转圈。
posted @
2006-11-02 12:25 Stefanie 阅读(2278) |
评论 (0) |
编辑 收藏