1、宙斯Zeus：天神之父，也是众神之神，地上万物的最高统治者。用雷霆和叫做“埃奎斯”的神盾治理天和地。同时，宙斯还是个花心大萝卜，到处拈花惹草使他的妻子赫拉嫉妒。

　　2、赫拉Hera：宙斯的妻子，神圣的婚姻女神，掌管婚姻，捍卫家庭。赫拉相当冷静并且拥有美好的身材。性格特征是嫉妒。

　　3、波塞冬Poseidon：海神，仅次于宙斯的强大的掌权者。波塞冬具有强大的力量，但他是一个头脑简单的神。他的兵器是三叉戟。

　　4、赫斯提亚Hestia：炉灶、火焰女神。谦让、随和、心地善良，深受众神的爱戴。

　　5、德墨忒尔Demeter：谷物、大地女神。她有着温和的态度、热情的笑容，但她很胆小。

　　6、阿佛洛狄忒Aphrodite：爱和美的女神。就是人们常说的维纳斯。她拥有白瓷般的肌肤，是个金发碧眼的美人。她是优雅和迷人的混合体，所有她的行为和语言都值得保留并用作典范。

　　7、阿波罗Apollon：太阳神，同时也是音乐、预言、弓箭、医疗之神。阿波罗是男神中最英俊的，他快乐、聪明，拥有阳光般明亮的气质，总是充满了勇气和力量，女人们都喜欢他。

　　8、雅典娜Athena：主管胜利、智慧和技艺的战争女神。她是从父亲宙斯的脑袋里诞生的女神，少言寡语，极具智慧，外表很酷，拥有很多“fans”。

　　9、阿瑞斯Ares：战神。总是一身盔甲，长相英俊，但因脾气暴躁喜欢大喊大叫众神都不太喜欢他，但偏偏爱与美的女神阿佛洛狄忒钟情于他。

　　10、阿尔忒弥斯Arthemis：月亮和狩猎女神，又是美丽而纯洁的处女神。她非常迷人，思维敏捷，做事果断，奔跑迅速，因此总是不可能在一个地方逗留太长的时间。

　　11、赫尔墨斯Hermes：宙斯的随从，牧童和游子之神。他是位兼具才华和魅力的神，常带着恶作剧般的微笑，行动迅速，是众神中最忙碌的一个。众神都很喜欢他。

　　12、赫菲斯托斯Hephaestus：手艺异常高超的铁匠之神。他又驼又瘸，是众神中最丑陋的神。但他的心地非常善良。

　　除了上面提到的十二大主神外，古希腊神话还有其他一些重要的神，他们是：

　　1、大地女神盖亚

　　2、天空之神乌拉诺斯

　　3、墨提斯，智慧女神，宙斯的妻子

　　4、提丰，身躯硕大，眼中冒火，头上长着数百条蛇，吐出猩红的信子。

　　5、普罗米修斯兄弟

　　6、勒托,阿波罗和阿尔忒弥斯的母亲

　　7、精灵达佛涅，后变成月桂树

　　8、长有一百只眼睛的巨人阿尔戈斯

　　9、在众神间传递消息的彩虹女神伊丽丝

　　10、酒神狄奥尼索斯

　　11、爱神埃罗斯

　　12、阴间之王哈得斯

　　诸神谱系：古希腊罗马神话是人类的神话中唯一系统的神话，经过整理，人们能看到一个较为清晰的众神谱系。

十二星座希腊神话起源

星座传说--牧羊座 

　　特寒里亚国王阿塔玛斯和王妃涅佩拉结婚，两人生了一对双胞胎，但国王却和特贝的公主伊诺娃有段婚外情，将涅佩拉王妃赶出宫，而迎立诺娃为新妃。当伊诺娃王妃有了自己的孩子后，乃决定要杀死前涅佩拉王妃所留下的唯一双胞胎，(哥哥是普里克思，妹妹是赫雷)。她收买占星师向国王告状：若不将前王妃所生的孩子送给宙斯当祭品，众神将大怒，则今年将闹饥荒。涅佩拉知道后就向宙斯求救，于是宙斯就派天上的黄金牡羊去载这两兄妹至天空彼方。因速度太快，妹妹跌落大海，牡羊就一边回头看妹妹，一边守护着哥哥，而形成现今的牡羊座。 

星座传说--金牛座

    经希腊哈莫尼亚地方的贝纳斯河，国王贝纳斯有位美丽的公主赫洛蓓。有一天，公主和侍女们到野外摘花，玩耍，突然出现一只如雪花般洁白的牛，以级温柔的眼光望着赫洛蓓，其实这只牛是仰慕公主美色的宙斯变的。一开始公主的确大吃一惊，但仍走向温驯的牛只身旁，轻轻抚摸它。由于公牛显得非常乖巧而温驯，于是公主就放心的爬到牛背上试骑，忽然间牛奔跑了起来，最后跳进爱琴海。公主紧抱着牛，海里生物皆出来向宙斯行礼，公主终于知道牛是宙斯的化身，到了克里特岛后，就和宙斯举行婚礼，化身为牛的宙斯和赫洛蓓公主过着幸福的日子。 

星座传说--双子座 

　　迷恋斯巴达王妃勒达美色的宙斯，为接近她而化身为天鹅，两人生了一对双胞胎-波拉克斯神子和人之子卡斯托。两人皆是骁勇冒险的武士，经常联手立下大功勋。他们二人也有一对双胞胎堂弟-伊达斯和林克斯。一天四人准备去抓牛，他们抓了很多牛，并准备平分时，贪心的伊达斯和林克斯趁波拉克斯，卡斯托兄弟不备时，将牛全部带回去。被激怒的两对双胞胎大起争执，结果伊达斯用箭将卡斯托刺死。波拉克斯伤心得要随卡斯托赴天国，但却因为拥有永远的生命而不能如愿。他的悲痛感动了宙斯，乃为他们二人设立星座，分别住在天国和死亡之国。 

星座传说--巨蟹座 

　　宙斯和人间女孩阿克梅妮生了儿子海格拉斯，海格拉斯后来和德贝的公主结婚，生了小孩过着美满的生活。由于宙斯正后赫拉的咒语，海格拉斯竟亲手刃妻，自己也正欲自杀，宙斯为了让他赎罪，乃任命为耶里斯特斯王，他必需经历十二大冒险行动，其中第二项是制服住在沼泽中的怪物西多拉。西多拉是只有九个头的巨蛇，躲在沼泽附近的洞窟内，海格拉斯对其投火炬，激怒的西多拉乃吐毒气攻击，同住在沼泽里的大巨蟹眼见西多拉苦战，乃跳出咬海格拉斯的脚，结果巨蟹被踩碎，西多拉也被制服。赫拉因感伤它的逝世，而在天上设立巨蟹座。 

星座传说--狮子座 

　　宙斯和阿克梅妮所生之子海格拉斯，被任命为耶里斯特斯王，要去执行十二项困难的任务，第一个任务是制服在涅梅谷的不死食人狮，这只狮子专吃家畜和村人，人人畏惧，以前曾有人来制服，但未见生还者。来到涅梅谷的海格拉斯也是迷了路好多天，才发现狮子的踪迹。海格拉斯欲射箭攻击，但因狮皮太硬而无效。用剑砍剑也弯掉了，于是用橄榄树制成粗棍，用力往狮头打去，此时不怕弓剑的狮子也畏惧发怒的海格拉斯，被海格拉斯绑住脖子，终于被他击退。女神赫拉为了感念这只狮子，乃在天上设立了狮子星座。 

星座传说--处女座 

　　农业女神得墨特尔和宙斯大帝育有一女普西芬妮，有一天普西芬妮在野地摘花时，有朵从为见过的美丽花朵正盛开着，正当她伸手要摘时，地面突然裂成好几块，就掉下去了。母亲得墨特尔誓死也要找回失踪的女儿而四处寻访。看到所有事情经过的太阳神赫利俄斯乃告诉得墨特尔，因冥王海德斯欲娶普西芬妮为妻，而将她带回地下，得墨特尔因为悲伤过度而使植物枯萎，大地一毛不生。宙斯看事态严重，乃向海德斯说情，可是海德斯在普西芬妮要走时，拿了冥界石榴给她吃，普西芬妮因为可以离开，高兴吃了四个，结果被迫一年有四个月要留在冥界，这四个月就变得今日万物不宜耕种的冬天，普西芬妮一回到人间就是春天，得墨特尔就是处女座的化身。 

星座传说--天秤座 

　　此乃正义女神亚斯托雷斯在为人类做善恶裁判时所用的天秤，亚斯托雷亚一只手持秤，一只手握斩除邪恶的剑。为求公正，所以眼睛皆蒙着。从前的众神和人类是和平共处于大地上，神虽拥有永远的生命，但人类寿命有限。因此寂寞的神只有不断创造人类，然而那时的人号好争斗，恶业横行，众神在对人类失望之余回到天上。只有亚斯托雷斯女神舍不得回去而留在世界上，教人为善。尽管如此，人类仍继续堕落，于是战争掀起，开始了打打杀杀。最后连亚斯托雷斯也放弃人类而回到天上。而天空就高挂着钟爱正义和平公正的天秤座。 

星座传说--天蝎座 

　　在古希腊时代，海神波塞顿的儿子奥立安是位有名的斗士，不仅是美少年，又是有强健体魄的男子，所以相当有女人缘。他本身也相当自豪，还曾大言不惭的公告天下：世界上没有比我更棒的人！赫拉女神听到后相当不悦，乃派出一只猛毒的天蝎去抓奥立安，并放逐到原来的地方。天蝎悄巧溜到毫不知情的奥立安身边，以其毒针向其后脚跟刺去，奥立安根本来不及有所反应，就已气绝身亡。因为有此功勋，所以天上就有天蝎座。即使现在，只要天蝎座从东方升起，奥立安座(猎户座)就敢紧向西方地平线隐藏沉没。 

星座传说--射手座 

　　从前有个半人半马族，乃是上半身为人，下半身为马的野蛮种族。然而在一群残暴的族人当中，只有收获之神克罗那斯的儿子肯农为贤明的半人半马，不仅懂得音乐，占星，还是海格拉斯的老师。有一天海格拉斯和族人起冲突，被追杀的他就逃入肯农家中，愤怒的海格拉斯就瞄准半马半人族频频放箭，却不知老师肯农也混在其中，而射到他的脚。因箭端沾了不死之身，所以无法从痛苦中解放。巨人神普罗米修斯乃废了其不死之身，让他安详而死，而成为天上的射手座。 

星座传说--摩羯座 

　　牧神潘恩是众神传信天使─汉密斯的儿子，他的相貌异常奇特，有着山羊角、蹄及胡子，他是个非常优秀的音乐家。由于潘恩能演出美妙的音乐带给众神欢乐，所以他常受被邀请到宴会中助兴。有一次，他应邀参加并为众神们吹奏时，大怪物提风突然出现并大肆倒乱。提风横冲直撞闯入宴会，众神们都纷纷走避。潘恩在慌忙中也化作鱼跳入尼罗河中，因为太过紧张的关系，只有下半身变成鱼尾，而上半身仍旧还是山羊的模样。这就成了半鱼半羊的山羊座。 

星座传说--水瓶座 

　　诸神之父─宙斯的妹妹希勒所生的女儿赫瑟,是奥林匹斯众神筵席中，招待和倒酒职员。自她嫁到别神府后，侍酒职务一直悬缺着。后来宙斯终于看上了一个年青英俊的特洛依王子─加尼米德。众神们也一致同意由他来担任侍酒一职，宙斯便派使者前去邀请。可是加尼米德爱好自由、放荡不羁，怎样也不答应宙斯的邀请。宙斯知道后十分愤怒，他不但将加尼米德抓回，还迫使他永远担任行侍者的工作，而宝瓶中的水成为众神智能的泉源。这就是水瓶座的起源。 

星座传说--双鱼座 

　　有一天众神因为天气佳之故，乃在河畔设宴。爱好音乐的众神们快乐的唱歌和弹奏乐器，气氛相当热络。突然传来凄厉的叫声，这就是肩膀下长出一百尾蛇，拥有大羽翼怪物的杰凡。众神一看不妙，乃四处逃走，宙斯化为鸟，阿波罗化为乌鸦，赫拉化为牡牛，裘林梭斯化为山羊，众神皆以动物之姿逃离。爱和美之女神阿弗罗裘特与其子恋爱之神耶罗斯乃化身为鱼，遁入尤法拉特斯河中。那时彼此决定用缎带将两人尾巴绑在一起，永不分开，就这样顺利从怪物手中逃脱。母子俩就这样以尾巴相连，永不分离的姿势升天，这就是双鱼座的由来。 

    僧人解释道：那具海滩上的女尸吗，就是你未婚妻的前世，你是第2个路过的人，曾给过他一件衣服。她今生和你相恋，只为还你一个情。但是她最终要报答一生一世的人，是最後那个把她掩埋的人，那人就是他现在的丈夫。

     书生大悟 ，唰地从床上做起，病愈！

     几年前 , 初恋的爱人去世时,我痛不欲生，有朋友就找来这故事开导我， 让我释怀不少。也许，她来到这个世界上 , 就是为了还我一片情吧。她做完了她想做的事,就走了。以後，我都用这个故事开导身边的朋友。

     缘这个东西，是最不可思议的。

     电影《 不见不散》 的主题歌。这样唱道：

    “这世界说大就大，说小就小，

      就算是我们今生的约定，也要用一生去寻找 ......"

    我们都在参加一场宏大的化装舞会，熙熙攘攘的人群里，我们寻觅着，渴望着那指间，相触时被电击的感觉。那一刻，面具摘下了，显现出真实的面目。这之前 , 我们都惶惑着,惶惑得甚至不知道自己需要的究竟是什麽。

    直到你遇到一个人 , 才恍然间了解了自己。真正想要的, 并非当初以为的。你惊讶于自己在对方面前表现出来的，竟然是和过去截然不同的你！皆因你过去戴着面具。

   缘分这东西不可强求。

   该你的，早晚是你的：

   不该你的，怎麽努力也得不到。

   无论任何时候，我们都不要绝望 。

   不要放弃自己对真,善,美的爱情追求。

   人生的价值，在某种意义上讲，就是爱和被爱的成熟。

   当真爱来临，结果也就成熟了。

   是我们难以割舍对方那厚重的情感。

   只有疼痛过才会记住

   如果不痛就只有遗忘

   伸出手抓住你的幸福吧

      书中着力介绍了Sping、Hibernate、WebWork等都是时下流行的开源框架，Ioc、AOP之类都是时下流行的概念名词。而最大的看点则是“without EJB”，我们曾经在无数的书籍和文章中看到，EJB是J2EE的核心技术之一；而Rod Johnson的这本书竟然宣传，绝大多数的J2EE应用根本不需要EJB。这无疑是向J2EE的架构师们摆起了挑衅的姿态。但所有这些尽皆不是本书的最大的价值所在，选择一种架构、一种技术的依据是什么？Rod Johnson认为，应该是基于实践的证据、来自历史项目或亲自试验的经验，而不是任何形式的偶像崇拜或者门户之见。

     “帕累托法则”，这个法则也常常被称为“80/20(或者90/10)法则”，也就是说：花比较少(10%-20%)的力气就可以解决大部分的问题，而要解决剩下的少部分问题则需要多得多的努力。在软件架构这里，这个法则告诉我们：架构的价值在于为常见的问题找到好的解决方案，而不是一心想要解决更复杂也更罕见的问题。

      这几年来，在J2EE社群里，WEB层结构出现了两种趋势：以Jakarta的Struts、OpenSymphony的WebWork2和Sping的web MVC框架为代表的请求驱动类型以及Tapestry和JSF是以事件为驱动MVC的类型。Struts的核心概念是：action必须继承org.apache.struts.actionl.Action基类，action是控制器组件，它类似于servlet：可以重用，并且是线程安全的对象。但Struts1.1的标准框架中不提供任何形式的拦截器，虽一个名为SAIF的附加项目则实现了这样的功能，但它的适用的范围还很有限。WebWork2是WebWork全新的改版，它是一个流行的web MVC开源框架，WebWork2最终版在2004年2月发布。它与Struts的不同在于它一直致力于减少应用代码对servlet API的依赖，提升可重用性。Spring提供了一个Web框架，它是建立在Spring的核心概念－IoC的应用上下文之上，并将其扩展到Web环境，与中间层应用上下文之间无缝结合。由于Spring的分层架构，Spring中间层上下文也能容易地集成到不同的Web框架中，在Spring和专用Web框架之间最根本的区别是：Spring将它的Web MVC框架作为总体方案的一部分，因此它被设计为松散耦合，并且无缝的和Spring中间层丰富的IoC和AOP管理功能融为一体。Tapstry是Howard Lewis Ship开发的开源Web MVC框架，它致力于彻底分离java代码和HTML模板的分离。而在2001年的JavaOne大会上，Sun宣布了一个新的JSR：JSF，它的目标是创建一个很适合GUI开发工具的、基于JSP的web MVC框架。JSF最终在2004年3月被发布。JSF采用了基于事件的风格，但它提供了与Tapstry完全不同的编程模型。它的焦点是大量使用JSP标签库来构建表单，并在JSP代码中嵌入验证器和导航规则的引用。Tapstry和JSF都分享了ASP.NET的某些概念：Tapstry偏重于“页面类”，JSF则偏重于动态Web页和工具支持。

      EJB的强大在于是把组件模型和企业级服务合二为一，使得EJB组件可以通过声明性或者编程性的方式使用企业级服务，但EJB最大的问题不是对于远程调用或是session bean的技术解决方案，关键在于EJB的侵入性太强，用起来又那么复杂。而这正是轻量级容器最重要的优势之一，它是借助控制反转的配置来达成无侵入性的目标的。     

      就目前软件行业的发展来看：Spring提供了目前最强大的轻量级IoC容器。另外也有其他的开源框架：WebWork、PicoContainer、HiveMind、Nanning Aspects、AspectWerkz、JBoss4、AspectJ。比entity bean优秀的持久化框架包括：JDO、Hibernate、TopLink，对于大多数项目，推荐使用Hibernate或者JDO。在不适合使用O/R映射的时候，还可以通过iBatis数据库层或者Spring提供的JDBC包高效地访问数据。轻量级的IoC容器在实现J2EE应用方面有着巨大的优势，相信IoC将与AOP一道成为下一代J2EE构架的基础。

      从以前的Sun Java PetStroe和最近的Oracle Virtual J2EE Shopping Mall 等示例应用中可以看出“经典”J2EE架构的特征是将业务对象建模为带远程接口的EJB，并用entity bean来处理持久化，而EJB3.0的出现，不管是“后EJB架构”时代的信徒还是轻量级框架开源项目的崇拜者，我们有理由相信Spring提供的价值是独一无二的，而控制反转(IoC)和AOP是任何“EJB接班人”所必备的。

AOP应用范围

　　很明显，AOP非常适合开发J2EE容器服务器，目前JBoss 4.0正是使用AOP框架进行开发。

　　具体功能如下：

Authentication 权限

Caching 缓存

Context passing 内容传递

Error handling 错误处理

Lazy loading　懒加载

Debugging　　调试

logging, tracing, profiling and monitoring　记录跟踪　优化　校准

Performance optimization　性能优化

Persistence　　持久化

Resource pooling　资源池

Synchronization　同步

Transactions 事务

AOP有必要吗？

　　当然，上述应用范例在没有使用AOP情况下，也得到了解决，例如JBoss 3.XXX也提供了上述应用功能，但是没有使用AOP。

　　但是，使用AOP可以让我们从一个更高的抽象概念来理解软件系统，AOP也许提供一种有价值的工具。可以这么说：因为使用AOP结构，现在JBoss 4.0的源码要比JBoss 3.X容易理解多了，这对于一个大型复杂系统来说是非常重要的。

　　从另外一个方面说，好像不是所有的人都需要关心AOP，它可能是一种架构设计的选择，如果选择J2EE系统，AOP关注的上述通用方面都已经被J2EE容器实现了，J2EE应用系统开发者可能需要更多地关注行业应用方面aspect。

AOP具体实现

　　AOP是一个概念，并没有设定具体语言的实现，它能克服那些只有单继承特性语言的缺点（如Java），目前AOP具体实现有以下几个项目：

　　AspectJ (TM)：　创建于Xerox PARC. 有近十年历史，成熟

　　缺点：过于复杂；破坏封装；需要专门的Java编译器。

　　动态AOP：使用JDK的动态代理API或字节码Bytecode处理技术。

　　基于动态代理API的具体项目有：

　　JBoss 4.0 JBoss 4.0服务器

　　nanning　这是以中国南宁命名的一个项目，搞不清楚为什么和中国相关？是中国人发起的？

　　基于字节码的项目有：

　　aspectwerkz　

　　spring　？

     多个访问类同时访问一个共享数据对象时，每个访问类在访问这个数据对象时，需要将数据对象上锁，访问完成后，再实行解锁，供其它并发线程访问，这是我们处理并发访问资源的方式。

     为了实现这个需求，先实现传统的编程，这里我们假定有一个写锁，对数据对象实行写之前，首先对这个对象进行上写锁，写操作完毕后，必须释放写锁。

　　首先，我们需要一个锁，这个锁可以是数据对象中一个字段或其它，这里使用Doug Lea的ReentrantWriterPreferenceReadWriteLock作为我们的锁资源。

import EDU.oswego.cs.dl.util.concurrent.*;

public class Worker extends Thread {

　　Data data;

　　ReentrantWriterPreferenceReadWriteLock rwl =　

　　　　new ReentrantWriterPreferenceReadWriteLock();

　　public boolean createData() {

　　　try {

　　　　rwl.writeLock().acquire();　//上锁

　　　　//对data实行写逻辑操作　

　　　}catch() {

　　　 return false;

　　　}finally{

　　　 rwl.writeLock().release(); 　//解锁

　　　}

　　　return true;

　　}

　　public boolean updateData() {

　　　try {

　　　　rwl.writeLock().acquire();//上锁

　　　　//对data实行写逻辑操作　

　　　}catch() {

　　　 return false;

　　　}finally{

　　　 rwl.writeLock().release(); //解锁

　　　}

　　　return true;

　　}

　　public void run() {

　　　　//执行createData()或updateData()

　　}

}

假设可能存在另外一个访问类，也将对数据对象实现写操作，代码如下：

import EDU.oswego.cs.dl.util.concurrent.*;

public class AnotherWorker extends Thread {

　　Data data;

　　ReentrantWriterPreferenceReadWriteLock rwl =　

　　　　new ReentrantWriterPreferenceReadWriteLock();

　　public boolean updateData() {

　　　try {

　　　　rwl.writeLock().acquire();//上锁

　　　　//对data实行写逻辑操作　

　　　}catch() {

　　　 return false;

　　　}finally{

　　　 rwl.writeLock().release(); //解锁

　　　}

　　　return true;

　　}

　　public void run() {

　　　　//执行updateData()

　　}

}

　　以上是Java传统编程的实现，这种锁的实现方式是在每个具体类中实现。
    这种实现方式的缺点很多：

• 冗余：有很多重复的编码，如rwl.writeLock().acquire()等；
• 减少重用：worker的updateData()方法重用性几乎为零。
• "数据对象写操作必须使用锁控制这个设计目的"不容易显现，如果更换了一个新的程序员，他可能编写一段不使用锁机制就对这个数据对象写操作的代码。
• 如果上述代码有读功能，那么我们需要在代码中实现先上读锁，当需要写时，解读锁，再上写锁等等，如果稍微不小心，上锁解锁次序搞错，系统就隐含大的BUG，这种可能性会随着这个数据对象永远存在下去，系统设计大大的隐患啊！

　　那么我们使用AOP概念来重新实现上述需求，AOP并没有什么新花招，只是提供了观察问题的一个新视角度。

　　这里我们可以抛开新技术迷人雾障，真正核心还是新思维、新视点，人类很多问题如果换一个脑筋看待理解，也许结果真的是翻天覆地不一样啊，所以，作为人自身，首先要重视和你世界观和思维方式不一样的人进行交流和沟通。

　　现实生活中有很多"不公平"，例如某个小学毕业生成了千万富翁，你就怀疑知识无用，也许你认为他的机会好，其实你可能不知道，他的观察问题的视角比你独特，或者他可能会经常换不同的角度来看待问题和解决问题，而你由于过分陷入一个视角的具体实现细节中，迷失了真正的方向，要不说是读书人脑子僵化呢？

　　言归正传，我们看看AOP是如何从一个新的视角解决上述问题的。

　　如果说上面代码在每个类中实现上锁或解锁，类似横向解决方式，那么AOP是从纵向方面来解决上述问题。

　　AOP把这个纵向切面cross-cuts称为Aspect（方面），其实我认为AOP翻译成面向切面编程比较好，不知哪个糊涂者因为先行一步，翻译成“面向方面编程”如此抽象，故弄玄虚。

AspectJ实现

　　下面我们使用AOP的实现之一AspectJ来对上述需求改写。AspectJ是AOP最早成熟的Java实现，它稍微扩展了一下Java语言，增加了一些Keyword等，pointcut的语法如下：

public pointcut 方法名：call(XXXX)

　　AspectJ增加了pointcut, call是pointcut类型，有关AspectJ更多基本语法见这里。因为AspectJ使用了一些特别语法，所以Java编译器就不能用SUN公司提供javac了，必须使用其专门的编译器，也许SUN在以后JDK版本中会引入AOP。

　　使用AspectJ如何实现上图所谓切面式的编程呢？首先,我们将上图纵向切面称为Aspect，那么我们建立一个类似Class的Aspect，Java中建立一个Class代码如下：

public class MyClass{

　　//属性和方法 ...

}

　　同样，建立一个Aspect的代码如下：

public aspect MyAspect{

　　//属性和方法 ...

}

建立一个Aspect名为Lock，代码如下：

import EDU.oswego.cs.dl.util.concurrent.*;

public aspect Lock {

　　......

　　ReentrantWriterPreferenceReadWriteLock rwl =　

　　　　new ReentrantWriterPreferenceReadWriteLock();

　　public pointcut writeOperations():

　　　　execution(public boolean Worker.createData()) ||

　　　　execution(public boolean Worker.updateData()) ||

　　　　execution(public boolean AnotherWorker.updateData()) ;

　　before() : writeOperations() {

　　　　rwl.writeLock().acquire();//上锁　advice body

　　}

　　after() : writeOperations() {

　　　 rwl.writeLock().release(); //解锁 advice body

　　}

　　......

}

　　上述代码关键点是pointcut，意味切入点或触发点，那么在那些条件下该点会触发呢？是后面红字标识的一些情况，在执行Worker的createData()方法，Worker的update方法等时触发。

　　before代表触发之前做什么事情？

　　答案是上锁。

　　after代表触发之后做什么事情？

　　答案是上锁。

　　通过引入上述aspect，那么Worker代码可以清洁如下：

public class Worker extends Thread {

　　Data data;

　　public boolean createData() {

　　　try {

　　　　//对data实行写逻辑操作　　　　　　　　

　　　}catch() {

　　　 return false;

　　　}

　　　return true;

　　}

　　public boolean updateData() {

　　　try {

　　　　//对data实行写逻辑操作　　　　　　　　

　　　}catch() {

　　　 return false;

　　　}finally{

　　　}

　　　return true;

　　}

　　public void run() {

　　　　//执行createData()或updateData()

　　}

}

　　Worker中关于“锁”的代码都不见了，纯粹变成了数据操作的主要方法。

AOP术语

　　通过上例已经知道AspectJ如何从切面crosscutting来解决并发访问应用需求的，其中最重要的是引入了一套类似事件触发机制。

　　Pointcut类似触发器，是事件Event发生源，一旦pointcut被触发，将会产生相应的动作Action，这部分Action称为Advice。

　　Advice在AspectJ有三种：before、 after、Around之分，上述aspect Lock代码中使用了Advice的两种before和after。

　　所以AOP有两个基本的术语：Pointcut和Advice。你可以用事件机制的Event和Action来类比理解它们。

小结如下：

Advice(增强) - 真正的执行代码，或者说关注的实现。 类似Action。

join point(连接点) - 代码中激活advice被执行的触发点。

Pointcut(切入点) - 一系列的join point称为pointcut，pointcut有时代指join point

其中advice部分又有：

Interceptor - 解释器并没有在AspectJ出现，在使用JDK动态代理API实现的AOP框架中使用，解释有方法调用或对象构造或者字段访问等事件，是调用者和被调用者之间的纽带，综合了Decorator/代理模式甚至职责链等模式。

Introduction - 修改一个类，以增加字段、方法或构造或者执行新的接口，包括Mixin实现。

例如上述并发访问应用中，如果想为每个Data对象生成相应的aspect Lock，那么可以在aspect Lock中人为数据对象增加一个字段lock，如下：

aspect Lock {

　　Data sharedDataInstance;

　　Lock( Data d ) {

　　　　 sharedDataInstance = d;

　　}

　　introduce Lock Data.lock;　//修改Data类，增加一字段lock

　　advise Data() { //Data构造时触发

　　　　 static after {

　　　　　　 //当Data对象生成时，将Data中lock字段赋值为aspect Lock

　　　　　　 //为每个Data对象生成相应的aspect Lock

　　　　　　 thisObject.lock = new Lock( thisObject );

　　　　 }

　　 }

　　....

}

上述代码等于在Data类中加入一行：

public class Data{

　　......

　　Lock lock = new Lock();

　　......

}

还有其它两个涉及AOP代码运行方式：

weaving - 将aspect代码插入到相应代码中的过程，一般是编译完成或在运行时动态完成。取决于具体AOP产品，例如AspectJ是使用特殊编译器在编译完成weaving，而nanning、JBoss AOP是使用动态代理API，因此在运行时动态完成weaving的。

instrumentor - 用来实现weaving功能的工具。

结束语

       AOP 与面向对象的设计和编程并不抵触，也不会代替它，相反，它是一种补充技术。横切关注点使代码污染出现于多个模块化单位之中，它干扰了核心业务逻辑，并产生了纠缠的、难于维护的和脆弱的代码。现有的编程语言和设计方法没有干净地分离横切关注点的机制。通过用切入点选择连接点，可以控制在什么时候和什么地方执行横切代码。用通知指定连接点匹配时执行的代码。类型间声明使您可以在现有类中加入新字段和方法作为方面的一部分。