少年阿宾

那些青春的岁月

  BlogJava :: 首页 :: 联系 :: 聚合  :: 管理
  500 Posts :: 0 Stories :: 135 Comments :: 0 Trackbacks

#

AOP

面向切面编程(AOP)通过提供另外一种思考程序结构的途经来弥补面向对象编程(OOP)的不足。在OOP中模块化的关键单元是类(classes),而在AOP中模块化的单元则是切面。切面能对关注点进行模块化,例如横切多个类型和对象的事务管理。(在AOP术语中通常称作横切(crosscutting)关注点。)

AOP框架是Spring的一个重要组成部分。但是Spring IoC容器并不依赖于AOP,这意味着你有权利选择是否使用AOP,AOP做为Spring IoC容器的一个补充,使它成为一个强大的中间件解决方案。

AOP即Aspect-Oriented Programming的缩写,中文意思是面向切面(或方面)编程。AOP实际上是一种编程思想,可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种思想。

AOP在Spring Framework中的作用

  • 提供声明式企业服务,特别是为了替代EJB声明式服务。最重要的服务是声明性事务管理

  • 允许用户实现自定义切面,用AOP来完善OOP的使用。

目前AOP主要有:Spring AOP ,JBOSS AOP ,AspectJ AOP

AOP与OOP:可以理解为OOP是纵向的采用继承树形式的。而AOP是横向的

Spring AOP:

由于Spring AOP是容易实现的,如果你计划在Spring Beans之上将横切关注点模块化,Spring的这一目标将是要点之一。但同样的目标也可能成为一个限制,如果你用的是普通的Java对象而不是Spring beans,并基于此将横切关注点模块化的话。另一方面,AspectJ可用于基于普通Java对象的模块化,但在实施之前需要良好的关于这个主题的知识。
 
Spring AOP致力于提供一种能够与Spring IoC紧密集成的面向方面框架的实现,以便于解决在开发企业级项目时面临的常见问题。明确你在应用横切关注点(cross-cutting concern)时(例如事物管理、日志或性能评估),需要处理的是Spring beans还是POJO。如果正在开发新的应用,则选择Spring AOP就没有什么阻力。但是如果你正在维护一个现有的应用(该应用并没有使用Spring框架),AspectJ就将是一个自然的选择了。为了详细说明这一点,假如你正在使用Spring AOP,当你想将日志功能作为一个通知(advice)加入到你的应用中,用于追踪程序流程,那么该通知(Advice)就只能应用在Spring beans的连接点(Joinpoint)之上。
 

AspectJ AOP:

使用“AspectJ”你可以在任何Java对象上应用通知,而不需要在任何文件中创建或配置任何bean。
 

另一个需要考虑的因素是,你是希望在编译期间进行织入(weaving),还是编译后(post-compile)或是运行时(run-time)。Spring只支持运行时织入。如果你有多个团队分别开发多个使用Spring编写的模块(导致生成多个jar文件,例如每个模块一个jar文件),并且其中一个团队想要在整个项目中的所有Spring bean(例如,包括已经被其他团队打包了的jar文件)上应用日志通知(在这里日志只是用于加入横切关注点的举例),那么通过配置该团队自己的Spring配置文件就可以轻松做到这一点。之所以可以这样做,就是因为Spring使用的是运行时织入。

 因为Spring基于代理模式(使用CGLIB),它有一个使用限制,即无法在使用final修饰的bean上应用横切关注点。因为代理需要对Java类进行继承,一旦使用了关键字final,这将是无法做到的。

在这种情况下,你也许会考虑使用AspectJ,其支持编译期织入且不需要生成代理。


于此相似,在static和final方法上应用横切关注点也是无法做到的。因为Spring基于代理模式。如果你在这些方法上配置通知,将导致运行时异常,因为static和final方法是不能被覆盖的。在这种情况下,你也会考虑使用AspectJ,因为其支持编译期织入且不需要生成代理。
 
缺点:
使用AspectJ的一个间接局限是,因为AspectJ通知可以应用于POJO之上,它有可能将通知应用于一个已配置的通知之上。对于一个你没有注意到这方面问题的大范围应用的通知,这有可能导致一个无限循环。
 

面向切面编程,把散落在程序中的公共部分提取出来,做成切面类,这样的好处在于,代码的可重用,一旦涉及到该功能的需求发生变化,只要修改该代码就行,否则,你要到处修改,如果只要修改1、2处那还可以接受,万一有1000处呢。 
AOP底层的东西就是JDK动态代理和CGLIB代理,说白了就是增强类的功能。 
最常用的AOP应用在数据库连接以及事务处理上。

AOP:面向切面编程。(Aspect-Oriented Programming)
AOP可以说是对OOP的补充和完善。OOP引入封装、继承和多态性等概念来建立一种对象层次结构,用以模拟公共行为的一个集合。当我们需要为分散的对象引入公共行为的时候,OOP则显得无能为力。也就是说,OOP允许你定义从上到下的关系,但并不适合定义从左到右的关系。例如日志功能。日志代码往往水平地散布在所有对象层次中,而与它所散布到的对象的核心功能毫无关系。在OOP设计中,它导致了大量代码的重复,而不利于各个模块的重用。
将程序中的交叉业务逻辑(比如安全,日志,事务等),封装成一个切面,然后注入到目标对象(具体业务逻辑)中去。

实现AOP的技术,主要分为两大类:一是采用动态代理技术,利用截取消息的方式,对该消息进行装饰,以取代原有对象行为的执行;二是采用静态织入的方式,引入特定的语法创建“方面”,从而使得编译器可以在编译期间织入有关“方面”的代码.

 AOP(Aspect Orient Programming),作为面向对象编程的一种补充,广泛应用于处理一些具有横切性质的系统级服务,如事务管理、安全检查、缓存、对象池管理等。 AOP 实现的关键就在于 AOP 框架自动创建的 AOP 代理,AOP 代理则可分为静态代理和动态代理两大类,其中静态代理是指使用 AOP 框架提供的命令进行编译,从而在编译阶段就可生成 AOP 代理类,因此也称为编译时增强;而动态代理则在运行时借助于 JDK 动态代理、CGLIB 等在内存中"临时"生成 AOP 动态代理类,因此也被称为运行时增强。









posted @ 2015-04-20 02:07 abin 阅读(421) | 评论 (0)编辑 收藏

先建立表:
CREATE TABLE `student` (                                  
           `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id',      
           `name` varchar(100) DEFAULT NULL COMMENT 'name',        
           `ban` varchar(100) DEFAULT NULL COMMENT 'ban',          
           `score` int(11) DEFAULT NULL,                           
           PRIMARY KEY (`id`),                                     
           KEY `inx_ban` (`ban`)                                   
         ) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=latin1  

name:学生名
ban:班级
score:分数
1、按班级分组排序,取出分数前两名的同学。
select t.ban,t.score,t.name from student t where 2<(select count(*) from student k where k.ban=t.ban and t.score>k.score order by k.ban desc) order by t.ban,t.score desc;
示例如下:
one 100 abin1
one 99 abin2
three 100 varyall1
three 99 varyall2
two 100 lee1
two 99 lee2
2、按组统计出来每组的所有分组,用逗号隔开
select t.ban,group_concat(t.score) from student t group by t.ban
示例如下:
one 100,99,97,95,91
three 100,99,97,95,91
two 100,99,97,95,91



posted @ 2015-04-17 01:29 abin 阅读(377) | 评论 (0)编辑 收藏

Spring控制反转(IoC)的理解

Spring框架的核心就是控制反转(Inversion of Control)和依赖注入(Dependency Injection),通过这两方面来实现松耦合。

使用IoC,对象是被动的接受依赖类,而不是自己主动的去找。容器在实例化的时候主动将它的依赖类注入给它。可以这样理解:控制反转将类的主动权转移到接口上,依赖注入通过xml配置文件在类实例化时将其依赖类注入。

    依赖类(Dependency)是通过外部(xml)来注入的,而不是由使用它的类(Business)来自己制造,这就是依赖的注入。另一方面,Business对类Dependency的依赖转移到对接口IDependency的依赖,控制权由类转移到了接口,即由"实现"转移到"抽象"中。这就是控制反转。
 
使用IoC,对象是被动的接受依赖类,而不是自己主动的去找。容器在实例化的时候主动将它的依赖类注入给它。可以这样理解:控制反转将类的主动权转移到接口上,依赖注入通过xml配置文件在类实例化时将其依赖类注入。

控制反转即IoC (Inversion of Control),它把传统上由程序代码直接操控的对象的调用权交给容器,通过容器来实现对象组件的装配和管理。所谓的“控制反转”概念就是对组件对象控制权的转移,从程序代码本身转移到了外部容器。

依赖注入(Dependency Injection)和控制反转(Inversion of Control)是同一个概念。具体含义是:当某个角色(可能是一个Java实例,调用者)需要另一个角色(另一个Java实例,被调用者)的协助时,在传统的程序设计过程中,通常由调用者来创建被调用者的实例。但在Spring里,创建被调用者的工作不再由调用者来完成,因此称为控制反转;创建被调用者实例的工作通常由Spring容器来完成,然后注入调用者,因此也称为依赖注入。
  简而言之:所谓控制反转就是应用本身不负责依赖对象的创建及维护,依赖对象的创建及维护是由外部容器负责的。这样控制权就由应用转移到了外部容器,控制权的转移就是所谓反转;所谓依赖注入就是指:在运行期,由外部容器动态地将依赖对象注入到组件中。


传统编程和IoC的对比
传统编程:决定使用哪个具体的实现类的控制权在调用类本身,在编译阶段就确定了。
IoC模式:调用类只依赖接口,而不依赖具体的实现类,减少了耦合。控制权交给了容器,在运行的时候才由容器决定将具体的实现动态的“注入”到调用类的对象中。


应用控制反转,对象在被创建的时候,由一个调控系统内所有对象的外界实体将其所依赖的对象的引用传递给它。也可以说,依赖被注入到对象中。所以,控制反转是,关于一个对象如何获取他所依赖的对象的引用,这个责任的反转。


IoC核心理念:

1.在类当中不创建对象,在代码中不直接与对象和服务连接

2.在配置文件中描述创建对象的方式,以及各个组件之间的联系

3.外部容器通过解析配置文件,通过反射来将这些联系在一起

 

The Hollywood principle:Don’t call us,we’ll call you.

即,所有组件都是被动的、不主动联系(调用)外部代码,

要等着外部代码的调用--------所有的组件的初始化和相互调用都由容器负责实现。

简单的说,就是整个程序之间的关系,都由容器来控制:将程序的控制权反转给容器,就是所谓的外转

而在我们传统代码中,由程序代码直接控制


优缺点:
IoC最大的好处是什么?
    因为把对象生成放在了XML里定义,所以当我们需要换一个实现子类将会变成很简单(一般这样的对象都是实现于某种接口的),只要修改XML就可以了,这样我们甚至可以实现对象的热插拔(有点象USB接口和SCSI硬盘了)。
IoC最大的缺点是什么?
    (1)生成一个对象的步骤变复杂了(事实上操作上还是挺简单的),对于不习惯这种方式的人,会觉得有些别扭和不直观。
    (2)对象生成因为是使用反射编程,在效率上有些损耗。但相对于IoC提高的维护性和灵活性来说,这点损耗是微不足道的,除非某对象的生成对效率要求特别高。
    (3)缺少IDE重构操作的支持,如果在Eclipse要对类改名,那么你还需要去XML文件里手工去改了,这似乎是所有XML方式的缺憾所在。


  IOC的意思是控件反转也就是由容器控制程序之间的关系,把控件权交给了外部容器,之前的写法,由程序代码直接操控,而现在控制权由应用代码中转到了外部容器,控制权的转移是所谓反转






posted @ 2015-04-15 13:36 abin 阅读(446) | 评论 (0)编辑 收藏

 下载一个dubbo.xsd文件
windows->preferrence->xml->xmlcatalog 

add->catalog entry  ->file system 选择刚刚下载的文件路径

修改key值和配置文件的http://code.alibabatech.com/schema/dubbo/dubbo.xsd 相同

保存。。在xml文件右键validate  ok解决了。

http://my.oschina.net/u/1455908/blog/343437
posted @ 2015-04-14 11:13 abin 阅读(351) | 评论 (0)编辑 收藏

初级优化:
1、select这些关键字大写,否则,系统会自动的转化为大写才去执行sql的解释执行计划。
2、如果需要字段少的话选择select a,b,c from table ,尽量少用select * from table.
3、尽量少使用!=和<>因为不会使用到索引。
4、尽量少使用or,不会使用到索引.
5、避免使用is not null 和not in,like,不会使用到索引。
6、避免全表扫描,在where和order by 上面建立索引。
7、应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如:
select id from t where num/2=100
应改为:
select id from t where num=100*2
8、应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。
9、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。





















posted @ 2015-04-08 21:33 abin 阅读(380) | 评论 (0)编辑 收藏

二叉树->b-树,解决的是读索引的IO次数问题

在真实的数据库中
往往索引本身的数据量也是非常庞大的
树的查找,其实是每一层需要做一次判断
因为索引很大,只能存在文件里,不能一次加载,所以没判断一层,都需要有一次磁盘IO,所以查找IO次数最坏的情况
就是树的高度-1,加入你要的节点在最后一层的话
二叉树,是只有两个子节点的
一单数据量一大的话
树高会很恐怖
B-Tree,的度是没有限制的
可以打打减少这个数的高度,从而减少磁盘读的次数


b-tree -> b+tree :这个是针对IO的再次优化
b+tree,的父节点是不存数据的
 数据库索引,其实一个节点刚好占的是硬盘的一页空间
 由于索引节点不存数据
 一个硬盘页,也就是一个节点的度就可以更大
 可以最大程度减少树的高度
 之所以一个节点刚好占一页,也是IO的问题,一次硬盘IO只能读一页
 这是结构上的改进
 效果就是一个节点一次IO的度更大了
 他这个意思就是说,如果有索引,一次索引查找,基本不会超过2次硬盘IO
 这还只是b-tree
 b-tree这玩意儿就读B树
 很多人读B减数是误读
























posted @ 2015-04-07 22:39 abin 阅读(398) | 评论 (0)编辑 收藏

1、JVM类装载机制,JVM内存模型,JVM垃圾回收算法,JVM垃圾回收器。
2、spring IOC和AOP机制。
3、http的get,post,put,delete,option。
4、Mybatis复杂数据类型实现,自增id返回机制。
5、多线程的ThreadLocal实现机制,volatile,线程池使用。
6、memcached的分片存储机制,redis优化。
7、mysql的myisam和innodb的区别,索引的概念和优化,mysql的主键索引和普通索引的区别,以及唯一索引。
 主键的数据域存储了整行的数据, 普通索引的数据域存的是主键
 联合索引这个,A=X AND C=X能用到的索引长度是A列的长度
A=X And B=X用到的索引长度是两列的长度和 
8、sql查询实现,以及优化sql。
9、数据库连接池异常怎么处理。















posted @ 2015-04-07 18:53 abin 阅读(312) | 评论 (0)编辑 收藏

服务端编程的性能杀手:
1、大量线程导致的线程切换开销。
2、锁和竞争条件。
3、非必要的内存拷贝。
4、网络IO
5、磁盘IO
6、CPU核心数
7、网络带宽
8、内存大小
9、
posted @ 2015-04-05 05:46 abin 阅读(352) | 评论 (0)编辑 收藏

1、线程问题
    由于Redis只使用单核,而Memcached可以使用多核,所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中,Memcached性能要高于Redis,虽然Redis最近也在存储大数据的性能上进行优化,但是比起 Memcached,还是稍有逊色。

因为 Redis 的操作都非常快速——它的数据全部在内存里,完全不需要访问磁盘。至于并发,Redis 使用多路 I/O 复用技术,本身的并发效率不成问题。

当然,单个 Redis 进程没办法使用多核(任一时刻只能跑在一个 CPU 核心上),但是它本来就不是非常计算密集型的服务。如果单核性能不够用,可以多开几个进程。

Redis 单线程-多路复用io模型

2、内存使用效率对比:
    使用简单的key-value存储的话,Memcached的内存利用率更高,而如果Redis采用hash结构来做key-value存储,由于其组合式的压缩,其内存利用率会高于Memcached。
3、数据类型:
    Redis相比Memcached来说,拥有更多的数据结构和并支持更丰富的数据操作,通常在Memcached 里,你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中,这些复杂的操作通常和一般的 GET/SET一样高效。所以,如果需要缓存能够支持更复杂的结构和操作,那么Redis会是不错的选择。
4、安全机制
    memcached采用cas机制,而redis有事务机制。
5、事件模型
    memcached采用了libevent事件模型,多线程模型可以发挥多核作用,Redis实现了自己的一套和libevent类似的事件驱动机制,两者都采用了epoll通信模型和非阻塞机制。

    epoll是在2.6内核中提出的,是之前的select和poll的增强版本。相对于select和poll来说,epoll更加灵活,没有描述符限制。epoll使用一个文件描述符管理多个描述符,将用户关系的文件描述符的事件存放到内核的一个事件表中,这样在用户空间和内核空间的copy只需一次。

 最后讲讲 为什么epoll会比select高效,主要从三方面来进行论述。
        (1)elect对描述符状态的改变是通过轮询来进行查找的;而epoll是当描述符状态发生改变时主动进行通知内核,这就是所谓的Reactor事件处理机制。可以用“好莱坞原则”进行描述:不要打电话给我们,我们会打电话通知你。相比之下,select的机制就好比面试结束后不停给面试官打电话询问面试结果。效率孰高孰低,可见一 斑。
        
       (2)select的文件描述符是使用链表进行组织的;而epoll是使用红黑树这一高效数据结构组织的。
        
       (3)select从内核到用户空间传递文件描述符上发送的信息是使用内存复制的方式进行的;而epoll是采用共享内存的方式。  
6、内存管理方面
  Memcached使用预分配的内存池的方式,使用slab和大小不同的chunk来管理内存,Item根据大小选择合适的chunk存储,内存池的方式可以省去申请/释放内存的开销,并且能减小内存碎片产生,但这种方式也会带来一定程度上的空间浪费,并且在内存仍然有很大空间时,新的数据也可能会被剔除,原因可以参考Timyang的文章:http://timyang.net/data/Memcached-lru-evictions/
  Redis使用现场申请内存的方式来存储数据,并且很少使用free-list等方式来优化内存分配,会在一定程度上存在内存碎片,Redis跟据存储命令参数,会把带过期时间的数据单独存放在一起,并把它们称为临时数据,非临时数据是永远不会被剔除的,即便物理内存不够,导致swap也不会剔除任何非临时数据(但会尝试剔除部分临时数据),这点上Redis更适合作为存储而不是cache。
7、redis并发

Redis 是一个高性能的key-value数据库。 redis的出现,很大程度补偿了memcached这类keyvalue存储的不足,在部 分场合可以对关系数据库起到很好的补充作用。它提供了Python,Ruby,Erlang,PHP客户端,使用很方便。

性能测试结果:

SET操作每秒钟 110000 次,GET操作每秒钟 81000 次,服务器配置如下:

Linux 2.6, Xeon X3320 2.5Ghz.

stackoverflow 网站使用 Redis 做为缓存服务器。





posted @ 2015-04-05 05:45 abin 阅读(558) | 评论 (0)编辑 收藏

中央仓库(官方和非官方)

https://repo1.maven.org/maven2
http://repo.maven.apache.org/maven2/
http://maven.oschina.net/content/groups/public/
http://download.java.net/maven/2/
https://repository.jboss.com/nexus/content/repositories/root_repository/maven2/
http://repository.jboss.com/maven2/
http://mirrors.ibiblio.org/maven2/
http://repository.sonatype.org/content/groups/public/

私有仓库
http://repository.codehaus.org/
http://snapshots.repository.codehaus.org/
http://people.apache.org/repo/m2-snapshot-repository/
http://people.apache.org/repo/m2-incubating-repository/
posted @ 2015-04-03 22:27 abin 阅读(401) | 评论 (0)编辑 收藏

仅列出标题
共50页: 上一页 1 2 3 4 5 6 7 8 9 下一页 Last