实际项目运用之Strategy模式(策略模式)

1. 策略模式概要 策略模式是对算法的包装,是把使用算法的责任和算法本身分割开来,委派给不同的对象管理。策略模式通常把一个系列的算法包装到一系列的策略类里面,作为一个抽象策略类的子类。用一句话来说,就是:“准备一组算法,并将每一个算法封装起来,使得它们可以互换”。 下面就以一个示意性的实现讲解策略模式实例的结构。  这个模式涉及到三个角色:  ● 环境(Context)角色:持有一个Strategy的引用。  ● 抽象策略(Strategy)角色:这是一个抽象角色,通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。  ● 具体策略(ConcreteStrategy)角色:包装了相关的算法或行为。 1.1 案例代码 策略模式上下文 public class Context { //持有一个具体策略的对象 private Strategy strategy; /** * 构造函数,传入一个具体策略对象 * @param strategy 具体策略对象 */ public Context(Strategy strategy){ this.strategy = strategy; } /** * 策略方法 */ public void contextInterface(){ strategy.algorithmInterface(); } } 抽象策略类 public interface Strategy { /** * 策略方法 */ public void algorithmInterface(); } 具体策略类 public class ConcreteStrategyA implements Strategy { @Override public void algorithmInterface() { //相关的业务 } } public class ConcreteStrategyB implements Strategy { @Override public void algorithmInterface() { //相关的业务 } } public class ConcreteStrategyC implements Strategy { @Override public void algorithmInterface() { //相关的业务 } } 客户端

volatile关键字原理实现及应用

1.并发编程中的三个概念 在并发编程中, 需要了解线程的三个概念:原子性,可见性,有序性: 1.1.原子性 原子性:即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断,要么就都不执行。 一个很经典的例子就是银行账户转账问题: 比如从账户A向账户B转1000元,那么必然包括2个操作:从账户A减去1000元,往账户B加上1000元。 试想一下,如果这2个操作不具备原子性,会造成什么样的后果。假如从账户A减去1000元之后,操作突然中止。然后又从B取出了500元,取出500元之后, 再执行 往账户B加上1000元 的操作。这样就会导致账户A虽然减去了1000元,但是账户B没有收到这个转过来的1000元。 所以这2个操作必须要具备原子性才能保证不出现一些意外的问题。  同样地反映到并发编程中会出现什么结果呢?  举个最简单的例子,大家想一下假如为一个32位的变量赋值过程不具备原子性的话,会发生什么后果? i = 9; 假若一个线程执行到这个语句时,我暂且假设为一个32位的变量赋值包括两个过程:为低16位赋值,为高16位赋值。 那么就可能发生一种情况:当将低16位数值写入之后,突然被中断,而此时又有一个线程去读取i的值,那么读取到的就是错误的数据。 1.2.可见性 可见性是指当多个线程访问同一个变量时,一个线程修改了这个变量的值,其他线程能够立即看得到修改的值。 举个简单的例子,看下面这段代码: //线程1执行的代码 int i = 0; i = 10; //线程2执行的代码 j = i;  假若执行线程1的是CPU1,执行线程2的是CPU2。由上面的分析可知,当线程1执行 i =10这句时,会先把i的初始值加载到CPU1的高速缓存中,然后赋值为10,那么在CPU1的高速缓存当中i的值变为10了,却没有立即写入到主存当中。  此时线程2执行 j = i,它会先去主存读取i的值并加载到CPU2的缓存当中,注意此时内存当中i的值还是0,那么就会使得j的值为0,而不是10. 这就是可见性问题,线程1对变量i修改了之后,线程2没有立即看到线程1修改的值。 1.3.有序性 有序性:即程序执行的顺序按照代码的逻辑顺序执行 举个简单的例子,看下面这段代码: int i = 0; boolean flag = false; i = 1; //语句1 flag = true; //语句2  上面代码定义了一个int型变量,定义了一个boolean类型变量,然后分别对两个变量进行赋值操作。从代码顺序上看,语句1是在语句2前面的,那么JVM在真正执行这段代码的时候会保证语句1一定会在语句2前面执行吗?不一定,为什么呢?这里可能会发生指令重排序。 但是要注意,虽然处理器会对指令进行重排序,但是它会保证程序最终结果会和代码顺序执行结果相同,那么它靠什么保证的呢?再看下面一个例子:

MYSQL高级特性之【Event事件】

一、基本概念 mysql5.1版本开始引进event概念。event既“时间触发器”,与triggers的事件触发不同,event类似与linux crontab计划任务,用于时间触发。通过单独或调用存储过程使用,在某一特定的时间点,触发相关的SQL语句或存储过程。 二、适用范围 对于每隔一段时间就有固定需求的操作,如创建表,删除数据等操作,可以使用event来处理。 例如:使用event在每月的1日凌晨1点自动创建下个月需要使用的三张表。 每天清除数据表中的过期的记录。 三、使用权限 单独使用event调用SQL语句时,查看和创建需要用户具有event权限,调用该SQL语句时,需要用户具有执行该SQL的权限。Event权限的设置保存在mysql.user表和mysql.db表的Event_priv字段中。 当event和procedure(存储过程)配合使用的时候,查看和创建存储过程需要用户具有create routine权限,调用存储过程执行时需要使用excute权限,存储过程调用具体的SQL语句时,需要用户具有执行该SQL的权限。 查看EVENT命令有如下几种: >(1)查询mysql.event表; (2)通过SHOW EVENTS命令; (3)通过SHOW FULL EVENTS命令; (4)通过查询information_schema.events表 (5)SHOW CREATE EVENT。 总之,event的使用频率较低建议使用root用户进行创建和维护。 四、基本语法 4.1 开启定时器 要使event起作用,MySQL的常量GLOBAL event_scheduler必须为on或者是1 – 查看是否开启定时器 SHOW VARIABLES LIKE 'event_scheduler'; – 开启定时器 0:off 1:on SET GLOBAL event_scheduler = 1; 当你设定事件计划为0 或OFF,即关闭事件计划进程的时候,不会有新的事件执行,但现有的正在运行的事件会执行到完毕 对于我们线上环境来说,使用event时,注意在主库上开启定时器,从库上关闭定时器,event触发所有操作均会记录binlog进行主从同步,从库上开启定时器很可能造成卡库。切换主库后之后记得将新主库上的定时器打开。 请特别注意! 4.2 创建事件 CREATE EVENT 的语法如下: CREATE EVENT [IF NOT EXISTS] ---------------------------------------------*标注1 event_name -----------------------------------------------------*标注2 ON SCHEDULE schedule ------------------------------------*标注3 [ON COMPLETION [NOT] PRESERVE] -----------------*标注4 [ENABLE | DISABLE] ----------------------------------------*标注5 [COMMENT 'comment'] --------------------------------------*标注6 DO sql_statement -----------------------------------------------*标注7 说明:

MYSQL高级特性之【存储过程与函数】

一、定义 存储程序可以分为存储过程和函数。 1.1 存储过程的定义 存储过程(Stored Procedure)是一组为了完成特定功能的SQL语句集。存储过程在数据库中经过第一次编译后再次调用不需要再次编译,用户通过指定存储过程的名字并给出参数(如果该存储过程带有参数)来执行它。 1.2 函数的定义 存储函数(简称函数)在本质上与存储过程没有区别。 只是函数有如:只能返回一个变量的限制,而存储过程可以返回多个。函数是可以嵌入在SQL中使用,可以在select中调用,而存储过程不行。 二、创建存储过程和函数 存储过程和函数的创建过程很相似。 2.1 创建存储过程 语法 >CREATE PROCEDURE sp_name ([ proc_parameter ]) [ characteristics..] routine_body proc_parameter指定存储过程的参数列表,列表形式如下: [IN|OUT|INOUT] param_name type 其中in表示输入参数,out表示输出参数,inout表示既可以输入也可以输出;param_name表示参数名称;type表示参数的类型 该类型可以是MYSQL数据库中的任意类型 有以下取值: characteristic: LANGUAGE SQL | [NOT] DETERMINISTIC | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA } | SQL SECURITY { DEFINER | INVOKER } | COMMENT 'string' routine_body: Valid SQL procedure statement or statements LANGUAGE SQL :说明routine_body部分是由SQL语句组成的,当前系统支持的语言为SQL,SQL是LANGUAGE特性的唯一值

分布式之【CAP理论、BASE理论 、FLP不可能定理】

1.分布式系统的CAP理论 1.1 CAP理论概述 2000年7月,加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后,麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后,CAP理论正式成为分布式计算领域的公认定理。 一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。 1.2 CAP的定义 1.2.1 Consistency 一致性 一致性指“all nodes see the same data at the same time”,即更新操作成功并返回客户端完成后,所有节点在同一时间的数据完全一致。分布式的一致性 对于一致性,可以分为从客户端和服务端两个不同的视角。从客户端来看,一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看,则是更新如何复制分布到整个系统,以保证数据最终一致。一致性是因为有并发读写才有的问题,因此在理解一致性的问题时,一定要注意结合考虑并发读写的场景。 从客户端角度,多进程并发访问时,更新过的数据在不同进程如何获取的不同策略,决定了不同的一致性。对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性。如果能容忍后续的部分或者全部访问不到,则是弱一致性。如果经过一段时间后要求能访问到更新后的数据,则是最终一致性。 1.2.2 Availability 可用性 可用性指“Reads and writes always succeed”,即服务一直可用,而且是正常响应时间。 对于一个可用性的分布式系统,每一个非故障的节点必须对每一个请求作出响应。也就是,该系统使用的任何算法必须最终终止。当同时要求分区容忍性时,这是一个很强的定义:即使是严重的网络错误,每个请求必须终止。 好的可用性主要是指系统能够很好的为用户服务,不出现用户操作失败或者访问超时等用户体验不好的情况。可用性通常情况下可用性和分布式数据冗余,负载均衡等有着很大的关联。 1.2.3 Partition Tolerance分区容错性 分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”,即分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。 分区容错性和扩展性紧密相关。在分布式应用中,可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求能够使应用虽然是一个分布式系统,而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了,其他剩下的机器还能够正常运转满足系统需求,或者是机器之间有网络异常,将分布式系统分隔未独立的几个部分,各个部分还能维持分布式系统的运作,这样就具有好的分区容错性。 1.3 CAP的证明 如上图,是我们证明CAP的基本场景,网络中有两个节点N1和N2,可以简单的理解N1和N2分别是两台计算机,他们之间网络可以连通,N1中有一个应用程序A,和一个数据库V,N2也有一个应用程序B2和一个数据库V。现在,A和B是分布式系统的两个部分,V是分布式系统的数据存储的两个子数据库。 在满足一致性的时候,N1和N2中的数据是一样的,V0=V0。在满足可用性的时候,用户不管是请求N1或者N2,都会得到立即响应。在满足分区容错性的情况下,N1和N2有任何一方宕机,或者网络不通的时候,都不会影响N1和N2彼此之间的正常运作。 如上图,是分布式系统正常运转的流程,用户向N1机器请求数据更新,程序A更新数据库Vo为V1,分布式系统将数据进行同步操作M,将V1同步的N2中V0,使得N2中的数据V0也更新为V1,N2中的数据再响应N2的请求。 这里,可以定义N1和N2的数据库V之间的数据是否一样为一致性;外部对N1和N2的请求响应为可用行;N1和N2之间的网络环境为分区容错性。这是正常运作的场景,也是理想的场景,然而现实是残酷的,当错误发生的时候,一致性和可用性还有分区容错性,是否能同时满足,还是说要进行取舍呢? 作为一个分布式系统,它和单机系统的最大区别,就在于网络,现在假设一种极端情况,N1和N2之间的网络断开了,我们要支持这种网络异常,相当于要满足分区容错性,能不能同时满足一致性和响应性呢?还是说要对他们进行取舍。 假设在N1和N2之间网络断开的时候,有用户向N1发送数据更新请求,那N1中的数据V0将被更新为V1,由于网络是断开的,所以分布式系统同步操作M,所以N2中的数据依旧是V0;这个时候,有用户向N2发送数据读取请求,由于数据还没有进行同步,应用程序没办法立即给用户返回最新的数据V1,怎么办呢?有二种选择,第一,牺牲数据一致性,响应旧的数据V0给用户;第二,牺牲可用性,阻塞等待,直到网络连接恢复,数据更新操作M完成之后,再给用户响应最新的数据V1。 这个过程,证明了要满足分区容错性的分布式系统,只能在一致性和可用性两者中,选择其中一个。 1.4 CAP权衡 通过CAP理论,我们知道无法同时满足一致性、可用性和分区容错性这三个特性,那要舍弃哪个呢?

字符串拼接的疑惑

最近没事在玩ASM框架,于是乎想将业务代码中的PO对象中的toString方法 在编译期间,自动转换了基于StringBuilder 拼接的代码。发现了一个奇怪的问题: 实体类如下 @Getter @Setter @EqualsAndHashCode(of = "id") @ApiModel("活动") public class Banner implements Serializable{ private static final long serialVersionUID = 191609922585601269L; @ApiModelProperty(value = "ID", position = 1) private Integer id; @ApiModelProperty(value = "显示次序", position = 2) private Integer orderNo; @ApiModelProperty(value = "关联文件", position = 3) private Integer fileId; @ApiModelProperty(value = "跳转链接", position = 4) private String forwardLink = ""; @ApiModelProperty(value = "创建时间", position = 5) private Long createDateline; @ApiModelProperty(value = "是否可用:1 可用,0 不可用", position = 6) private Integer isenable; @ApiModelProperty(value = "标题", position = 7) private String title = ""; @ApiModelProperty(value = "备注", position = 8) private String remark = ""; @ApiModelProperty(value = "banner类型:1.

Java异常处理-原理及优化建议

1 异常层次结构 异常指不期而至的各种状况,如:文件找不到、网络连接失败、非法参数等。异常是一个事件,它发生在程序运行期间,干扰了正常的指令流程。Java通 过API中Throwable类的众多子类描述各种不同的异常。因而,Java异常都是对象,是Throwable子类的实例,描述了出现在一段编码中的 错误条件。当条件生成时,错误将引发异常。 Java异常类层次结构图: 在 Java 中,所有的异常都有一个共同的祖先 Throwable(可抛出)。Throwable 指定代码中可用异常传播机制通过 Java 应用程序传输的任何问题的共性。 Throwable: 有两个重要的子类:*Exception(异常)和 Error(错误)*,二者都是 Java 异常处理的重要子类,各自都包含大量子类。 Error(错误):是程序无法处理的错误,表示运行应用程序中较严重问题。大多数错误与代码编写者执行的操作无关,而表示代码运行时 JVM(Java 虚拟机)出现的问题。例如,Java虚拟机运行错误(Virtual MachineError),当 JVM 不再有继续执行操作所需的内存资源时,将出现 OutOfMemoryError。这些异常发生时,Java虚拟机(JVM)一般会选择线程终止。这些错误表示故障发生于虚拟机自身、或者发生在虚拟机试图执行应用时,如Java虚拟机运行错误(Virtual MachineError)、类定义错误(NoClassDefFoundError)等。这些错误是不可查的,因为它们在应用程序的控制和处理能力之 外,而且绝大多数是程序运行时不允许出现的状况。对于设计合理的应用程序来说,即使确实发生了错误,本质上也不应该试图去处理它所引起的异常状况。在 Java中,错误通过Error的子类描述。 Exception(异常):是程序本身可以处理的异常。 Exception 类有一个重要的子类 RuntimeException。RuntimeException 类及其子类表示“JVM 常用操作”引发的错误。例如,若试图使用空值对象引用、除数为零或数组越界,则分别引发运行时异常(NullPointerException、ArithmeticException)和 ArrayIndexOutOfBoundException。 通常,Java的异常(包括Exception和Error)分为可查的异常(checked exceptions)和不可查的异常(unchecked exceptions)。 运行时异常:都是RuntimeException类及其子类异常,如NullPointerException(空指针异常)、IndexOutOfBoundsException(下标越界异常)等,这些异常是不检查异常,程序中可以选择捕获处理,也可以不处理。这些异常一般是由程序逻辑错误引起的,程序应该从逻辑角度尽可能避免这类异常的发生。 运行时异常的特点是Java编译器不会检查它,也就是说,当程序中可能出现这类异常,即使没有用try-catch语句捕获它,也没有用throws子句声明抛出它,也会编译通过。 非运行时异常 (编译异常):是RuntimeException以外的异常,类型上都属于Exception类及其子类。从程序语法角度讲是必须进行处理的异常,如果不处理,程序就不能编译通过。如IOException、SQLException等以及用户自定义的Exception异常,一般情况下不自定义检查异常。 2 JVM字节码分析异常处理机制 我们都知道 try、catch、finally语句块的执行顺序: 接下来我们从字节码的角度加深对异常机制的理解, 我们先反编译如下代码: public class FileDemo { private static void divideFun(int a, int b) { b = a - b; } public static void main(String[] args) { int a = 1; int b = 3; try { b = a + b; FilterInputStream filterInputStream = new BufferedInputStream(new FileInputStream("d:/a")); } catch (FileNotFoundException e) { System.

java内存模型之[JMM][重排序][happens-before]

1.并发编程模型的分类 在并发编程中,我们需要处理两个关键问题:线程之间如何通信及线程之间如何同 步(这里的线程是指并发执行的活动实体)。通信是指线程之间以何种机制来交换 信息。在命令式编程中,线程之间的通信机制有两种:*共享内存和消息传递*。 在共享内存的并发模型里,线程之间共享程序的公共状态,线程之间通过写-读内 存中的公共状态来隐式进行通信。在消息传递的并发模型里,线程之间没有公共状 态,线程之间必须通过明确的发送消息来显式进行通信。 同步是指程序用于控制不同线程之间操作发生相对顺序的机制。在共享内存并发模 型里,同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之 间互斥执行。在消息传递的并发模型里,由于消息的发送必须在消息的接收之前, 因此同步是隐式进行的。 Java 的并发采用的是共享内存模型,Java 线程之间的通信总是隐式进行,整个通 信过程对程序员完全透明。如果编写多线程程序的 Java 程序员不理解隐式进行的 线程之间通信的工作机制,很可能会遇到各种奇怪的内存可见性问题。 2.Java 内存模型的抽象 在java中,所有实例域、静态域和数组元素存储在堆内存中,堆内存在线程之间共 享(本文使用“共享变量”这个术语代指实例域,静态域和数组元素)。局部变量 ( Local variables ),方法定义参数(java语言规范称之为 formal method parameters )和异常处理器参数( exception handler parameters )不会在线程之间 共享,它们不会有内存可见性问题,也不受内存模型的影响。 Java 线程之间的通信由 Java 内存模型(本文简称为 JMM)控制,JMM 决定一个 线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看,JMM 定义了 线程和主内存之间的抽象关系:*线程之间的共享变量存储在主内存(main memory)中,每个线程都有一个私有的本地内存(local memory),本地内存 中存储了该线程以读/写共享变量的副本。*本地内存是 JMM 的一个抽象概念,并不 真实存在。它涵盖了缓存,写缓冲区,寄存器以及其他的硬件和编译器优化。 Java内存模型的抽象示意图如下: 从上图来看,线程 A 与线程 B 之间如要通信的话,必须要经历下面 2 个步骤: 1. 首先,线程 A 把本地内存 A 中更新过的共享变量刷新到主内存中去。 2. 然后,线程 B 到主内存中去读取线程 A 之前已更新过的共享变量。 下面通过示意图来说明这两个步骤: 如上图所示,本地内存 A 和 B 有主内存中共享变量 x 的副本。假设初始时,这三个 内存中的 x 值都为 0。线程 A 在执行时,把更新后的 x 值(假设值为 1)临时存放 在自己的本地内存 A 中。当线程 A 和线程 B 需要通信时,线程 A 首先会把自己本 地内存中修改后的 x 值刷新到主内存中,此时主内存中的 x 值变为了 1。随后,线 程 B 到主内存中去读取线程 A 更新后的 x 值,此时线程 B 的本地内存的 x 值也变 为了 1。 从整体来看,这两个步骤实质上是线程 A 在向线程 B 发送消息,而且这个通信过程 必须要经过主内存。JMM 通过控制主内存与每个线程的本地内存之间的交互,来 为 java 程序员提供内存可见性保证。

实际项目运用之Decorator模式(装饰器模式)

1 概述 在项目中,经常因一些新增需求,导致同一业务的变更,如果所在类继承关系如下:Parent、Child、Grandparent,那么要在Child类上增强些功能怎么办?给Child类增加方法?那会对Grandparent产生什么影响?该如何去处理?看完本文,你会找到你的答案。 JavaIO中,像下面的嵌套语句很常见,为什么要怎样定义呢?理解装饰模式后,你会找到答案。 FilterInputStream filterInputStreasm = new BufferedInputStream(new FileInputStream(new File("/user/a"))); 1.1案例 例如下面一个功能需求,4s店的汽车销售向客户推销自家品牌的产品,我们用代码实现,关系如下: 具体代码: 汽车销售类 public abstract class CarSale { /** * 推销车的详情 */ public abstract void displayCarInfo(); /** * 客户签订购买合同 */ public abstract void signContract(String customerName); } 汽车参数详情 public class CarInfo extends CarSale { @Override public void displayCarInfo() { System.out.println("日本丰田GTR"); System.out.println("百公里加速1秒"); System.out.println("油耗偏高"); System.out.println("后驱涡轮增压"); System.out.println("内饰豪华"); System.out.println("发动机噪音偏大"); System.out.println("不支持电动座椅,后视镜加热"); } @Override public void signContract(String customerName) { System.out.println("客户签约销售合同, 付款人:" + customerName); } } 客户

接口设计的幂等性考虑

分布式系统接口幂等性 1.幂等性定义 1.1 数学定义 在数学里,幂等有两种主要的定义:- 在某二元运算下,幂等元素是指被自己重复运算(或对于函数是为复合)的结果等于它自己的元素。例如,乘法下唯一两个幂等实数为0和1。即 s *s = s- 某一元运算为幂等的时,其作用在任一元素两次后会和其作用一次的结果相同。例如,高斯符号便是幂等的,即f(f(x)) = f(x)。 1.2 HTTP规范的定义 在HTTP/1.1规范中幂等性的定义是: A request method is considered “idempotent” if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent. HTTP的幂等性指的是一次和多次请求某一个资源应该具有相同的副作用。如通过PUT接口将数据的Status置为1,无论是第一次执行还是多次执行,获取到的结果应该是相同的,即执行完成之后Status =1。