首页 文章 精选 留言 我的

精选列表

搜索[php扩展],共10000篇文章
优秀的个人博客,低调大师

一次Zookeeper 扩展之殇

一、背景 基于公司发展硬性需求,生产VM服务器要统一迁移到ZStack 虚拟化服务器。检查自己项目使用的服务器,其中zookeeper集群中招,所以需要进行迁移。 二、迁移计划 为了使迁移不对业务产生影响,所以最好是采用扩容 -> 缩容 的方式进行。 说明: 1.原生产集群为VM-1,VM-2,VM-3组成一个3节点的ZK集群; 2.对该集群扩容,增加至6节点(新增ZS-1,ZS-2,ZS-3),进行数据同步完成; 3.进行缩容,下掉原先来的三个节点(VM-1,VM-2,VM-3); 4.替换nginx解析地址。 OK! 目标很明确,过程也很清晰,然后开干。 三、步骤 (过程已在测试环境验证无问题): 对新增的三台服务器进行zk环境配置,和老集群配置一样即可,最好使用同一版本(版主使用的是3.4.6); 对老节点的zoo.cfg 增加新

优秀的个人博客,低调大师

扩展Spring Cloud Feign 实现自动降级

自动降级目的 在Spring Cloud 使用feign 的时候,需要明确指定fallback 策略,不然会提示错误。 先来看默认的feign service 是要求怎么做的。feign service 定义一个 factory 和 fallback 的类 @FeignClient(value = ServiceNameConstants.UMPS_SERVICE, fallbackFactory = RemoteLogServiceFallbackFactory.class) public interface RemoteLogService {} 但是我们大多数情况的feign 降级策略为了保证幂等都会很简单,输出错误日志即可。类似如下代码,在企业中开发非常不方便 @Slf4j @Component public class Rem

优秀的个人博客,低调大师

synchronized的功能的扩展:重入锁

重入锁 重入锁可以说是synchronized,Object.wait(),Object.notify()的一种替代品。 在JDK5的早期版本,重入锁的新能要比synchronized好很多,在JDK6后对synchronized进行可很多优化,使得他和重入锁的性能差距并不大。 重入锁使用java.util.concurrent.locks.ReentrantLock类实现,下面我么来看下重入锁的简单使用案例: import java.util.*; import java.util.concurrent.locks.ReentrantLock; public class ReenterLock implements Runnable { public static ReentrantLock lock=new ReentrantLock(); public static int i=0; @Override public void run() { // TODO Auto-generated method stub for(int j=0;j<10000000;j++) { lock.lock(); try { i++; }finally { lock.unlock(); } } } public static void main(String[] args) throws InterruptedException { // TODO Auto-generated method stub ReenterLock tl=new ReenterLock(); Thread t1=new Thread(tl); Thread t2=new Thread(tl); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(i); } } 运行程序可以得到结果为20000000. 重入锁具有很高的灵活性,需要开发人员手动用lock()与unlock()函数来指定何时加锁何时解锁,但是需要注意的是,在离开临界区的时候要记得释放锁,否则其他线程就没有机会在访问临界区了。(之所以叫重入锁是因为这种锁可以反复进入,但是记得一个线程同时获得多少锁,也必须释放相同的次数) 重入锁除了使用上的灵活性,还有一些高级的功能。 中断响应 对于synchronized来说,如果一个线程在等待锁,那么结果只有两种情况,要么获得锁继续执行,要么保持等待。但是使用重入锁。则提供了另外一种可能,就是线程可以被中断。也就是说,在等待锁的过程中,线程可以取消对锁的请求。有些时候这么做是很有必要的,比如和好朋友约好去打球,等了半小时没到,街道电话得知朋友临时有事,不能来了,那么就打道回府了。这种情况对于处理死锁有一定的帮助。使用lockInterruptibly()函数表示重入锁可以响应中断。 锁申请限时等待 除了等待外部通知外,要避免死锁还有一种办法,就是限时等待。我么可以通过tryLock方法进行一次限时的等待。 try{ if(lock.tryLock(5,TimeUnit.SECONDS)){ Thread.sleep(6000); }else{ System.out.println("get lock failed"); } }catch(InterruptdeException e){ e.printStackTrace(); }finally{ if(lock.isHeldByCurrentThread()) lock.unlock();} } 上面代码中,设置的5秒的限时等待,由于睡眠了6秒,或导致请求锁失败。tryLock也可以不带参数进行运行,这种情况下,线程会尝试获得锁,如果锁未被其他线程占用,申请锁成功,返回true,否则申请失败,线程也不会进行等待,直接返回false。 公平锁 大多数情况下锁是不公平的,也就是说不一定先请求就先获得锁,使用synchronized关键字实现锁,锁就是不公平的,重入锁可以实现公平锁,避免现象,也就是说,只要你排队,就能获得锁,但是由于需要维护一个有序队列,导致公平锁的实现成本比较高,性能相对也非常低下。重入锁有如下一个构造函数:public ReentrantLock(boolean fair)当参数为true时锁是公平的的。 重入锁的好搭档:Condition条件 Condition与Object.wait(),Object.notify()方法的作用大致相同,只不过是用来与重入锁相关联的。通过Lock接口(出入锁就实现乐这一接口)的Condition newCondition()方法可以生成与当前重入锁对象绑定的Condition实例,利用Condition对象,我们可以让线程在特定的时刻进行等待,或者在某一个特定的时刻得到通知,继续执行。Condition接口提供的方法如下。 void await() throws InterrupttedExceptionI; void awaitUninterruptibly(); long awaitNanos(long nanosTimeout) throws InterrupttedExceptionI; boolean await(long time,TimeUnit unit) throws InterrupttedExceptionI; boolean awaitUntil(Date deadline) throws InterrupttedExceptionI; void signal(); void siganlAll(); 以上个方法的含义如下: await()方法会使当前线程等待,同时会释放锁,当其他线程中使用signal()或signalAll()方法的时候,线程会重新获得锁继续执行。或者线程被中断是也能跳出等待。 awaitUninterruptibly()方法与await()方法基本相同,但是他不会在等待过程中相应或者相应中断。 signal()用于唤醒一个在等待中的线程,同理signalAll()用于唤醒所有在等待中的线程。

优秀的个人博客,低调大师

Java 动态代理机制分析及扩展

简介:本文通过分析 Java 动态代理的机制和特点,解读动态代理类的源代码,并且模拟推演了动态代理类的可能实现,向读者阐述了一个完整的 Java 动态代理运作过程,希望能帮助读者加深对 Java 动态代理的理解和应用。 引言 Java 动态代理机制的出现,使得 Java 开发人员不用手工编写代理类,只要简单地指定一组接口及委托类对象,便能动态地获得代理类。代理类会负责将所有的方法调用分派到委托对象上反射执行,在分派执行的过程中,开发人员还可以按需调整委托类对象及其功能,这是一套非常灵活有弹性的代理框架。通过阅读本文,读者将会对 Java 动态代理机制有更加深入的理解。本文首先从 Java 动态代理的运行机制和特点出发,对其代码进行了分析,推演了动态生成类的内部实现。 回页首 代理:设计模式 代理是一种常用的设计模式,其目的就是为其他对象提供一个代理以控制对某个对象的访问。代理类负责为委托类预处理消息,过滤消息并转发消息,以及进行消息被委托类执行后的后续处理。 图 1. 代理模式 为了保持行为的一致性,代理类和委托类通常会实现相同的接口,所以在访问者看来两者没有丝毫的区别。通过代理类这中间一层,能有效控制对委托类对象的直接访问,也可以很好地隐藏和保护委托类对象,同时也为实施不同控制策略预留了空间,从而在设计上获得了更大的灵活性。Java 动态代理机制以巧妙的方式近乎完美地实践了代理模式的设计理念。 回页首 相关的类和接口 要了解 Java 动态代理的机制,首先需要了解以下相关的类或接口: java.lang.reflect.Proxy:这是 Java 动态代理机制的主类,它提供了一组静态方法来为一组接口动态地生成代理类及其对象。清单 1. Proxy 的静态方法 // 方法 1: 该方法用于获取指定代理对象所关联的调用处理器 static InvocationHandler getInvocationHandler(Object proxy) // 方法 2:该方法用于获取关联于指定类装载器和一组接口的动态代理类的类对象 static Class getProxyClass(ClassLoader loader, Class[] interfaces) // 方法 3:该方法用于判断指定类对象是否是一个动态代理类 static boolean isProxyClass(Class cl) // 方法 4:该方法用于为指定类装载器、一组接口及调用处理器生成动态代理类实例 static Object newProxyInstance(ClassLoader loader, Class[] interfaces, InvocationHandler h) java.lang.reflect.InvocationHandler:这是调用处理器接口,它自定义了一个 invoke 方法,用于集中处理在动态代理类对象上的方法调用,通常在该方法中实现对委托类的代理访问。清单 2. InvocationHandler 的核心方法 // 该方法负责集中处理动态代理类上的所有方法调用。第一个参数既是代理类实例,第二个参数是被调用的方法对象 // 第三个方法是调用参数。调用处理器根据这三个参数进行预处理或分派到委托类实例上发射执行 Object invoke(Object proxy, Method method, Object[] args) 每次生成动态代理类对象时都需要指定一个实现了该接口的调用处理器对象(参见 Proxy 静态方法 4 的第三个参数)。 java.lang.ClassLoader:这是类装载器类,负责将类的字节码装载到 Java 虚拟机(JVM)中并为其定义类对象,然后该类才能被使用。Proxy 静态方法生成动态代理类同样需要通过类装载器来进行装载才能使用,它与普通类的唯一区别就是其字节码是由 JVM 在运行时动态生成的而非预存在于任何一个 .class 文件中。 每次生成动态代理类对象时都需要指定一个类装载器对象(参见 Proxy 静态方法 4 的第一个参数) 回页首 代理机制及其特点 首先让我们来了解一下如何使用 Java 动态代理。具体有如下四步骤: 通过实现 InvocationHandler 接口创建自己的调用处理器; 通过为 Proxy 类指定 ClassLoader 对象和一组 interface 来创建动态代理类; 通过反射机制获得动态代理类的构造函数,其唯一参数类型是调用处理器接口类型; 通过构造函数创建动态代理类实例,构造时调用处理器对象作为参数被传入。 清单 3. 动态代理对象创建过程 // InvocationHandlerImpl 实现了 InvocationHandler 接口,并能实现方法调用从代理类到委托类的分派转发 // 其内部通常包含指向委托类实例的引用,用于真正执行分派转发过来的方法调用 InvocationHandler handler = new InvocationHandlerImpl(..); // 通过 Proxy 为包括 Interface 接口在内的一组接口动态创建代理类的类对象 Class clazz = Proxy.getProxyClass(classLoader, new Class[] { Interface.class, ... }); // 通过反射从生成的类对象获得构造函数对象 Constructor constructor = clazz.getConstructor(new Class[] { InvocationHandler.class }); // 通过构造函数对象创建动态代理类实例 Interface Proxy = (Interface)constructor.newInstance(new Object[] { handler }); 实际使用过程更加简单,因为 Proxy 的静态方法 newProxyInstance 已经为我们封装了步骤 2 到步骤 4 的过程,所以简化后的过程如下 清单 4. 简化的动态代理对象创建过程 // InvocationHandlerImpl 实现了 InvocationHandler 接口,并能实现方法调用从代理类到委托类的分派转发 InvocationHandler handler = new InvocationHandlerImpl(..); // 通过 Proxy 直接创建动态代理类实例 Interface proxy = (Interface)Proxy.newProxyInstance( classLoader, new Class[] { Interface.class }, handler ); 接下来让我们来了解一下 Java 动态代理机制的一些特点。 首先是动态生成的代理类本身的一些特点。1)包:如果所代理的接口都是 public 的,那么它将被定义在顶层包(即包路径为空),如果所代理的接口中有非 public 的接口(因为接口不能被定义为 protect 或 private,所以除 public 之外就是默认的 package 访问级别),那么它将被定义在该接口所在包(假设代理了 com.ibm.developerworks 包中的某非 public 接口 A,那么新生成的代理类所在的包就是 com.ibm.developerworks),这样设计的目的是为了最大程度的保证动态代理类不会因为包管理的问题而无法被成功定义并访问;2)类修饰符:该代理类具有 final 和 public 修饰符,意味着它可以被所有的类访问,但是不能被再度继承;3)类名:格式是“$ProxyN”,其中 N 是一个逐一递增的阿拉伯数字,代表 Proxy 类第 N 次生成的动态代理类,值得注意的一点是,并不是每次调用 Proxy 的静态方法创建动态代理类都会使得 N 值增加,原因是如果对同一组接口(包括接口排列的顺序相同)试图重复创建动态代理类,它会很聪明地返回先前已经创建好的代理类的类对象,而不会再尝试去创建一个全新的代理类,这样可以节省不必要的代码重复生成,提高了代理类的创建效率。4)类继承关系:该类的继承关系如图: 图 2. 动态代理类的继承图 由图可见,Proxy 类是它的父类,这个规则适用于所有由 Proxy 创建的动态代理类。而且该类还实现了其所代理的一组接口,这就是为什么它能够被安全地类型转换到其所代理的某接口的根本原因。 接下来让我们了解一下代理类实例的一些特点。每个实例都会关联一个调用处理器对象,可以通过 Proxy 提供的静态方法 getInvocationHandler 去获得代理类实例的调用处理器对象。在代理类实例上调用其代理的接口中所声明的方法时,这些方法最终都会由调用处理器的 invoke 方法执行,此外,值得注意的是,代理类的根类 java.lang.Object 中有三个方法也同样会被分派到调用处理器的 invoke 方法执行,它们是 hashCode,equals 和 toString,可能的原因有:一是因为这些方法为 public 且非 final 类型,能够被代理类覆盖;二是因为这些方法往往呈现出一个类的某种特征属性,具有一定的区分度,所以为了保证代理类与委托类对外的一致性,这三个方法也应该被分派到委托类执行。当代理的一组接口有重复声明的方法且该方法被调用时,代理类总是从排在最前面的接口中获取方法对象并分派给调用处理器,而无论代理类实例是否正在以该接口(或继承于该接口的某子接口)的形式被外部引用,因为在代理类内部无法区分其当前的被引用类型。 接着来了解一下被代理的一组接口有哪些特点。首先,要注意不能有重复的接口,以避免动态代理类代码生成时的编译错误。其次,这些接口对于类装载器必须可见,否则类装载器将无法链接它们,将会导致类定义失败。再次,需被代理的所有非 public 的接口必须在同一个包中,否则代理类生成也会失败。最后,接口的数目不能超过 65535,这是 JVM 设定的限制。 最后再来了解一下异常处理方面的特点。从调用处理器接口声明的方法中可以看到理论上它能够抛出任何类型的异常,因为所有的异常都继承于 Throwable 接口,但事实是否如此呢?答案是否定的,原因是我们必须遵守一个继承原则:即子类覆盖父类或实现父接口的方法时,抛出的异常必须在原方法支持的异常列表之内。所以虽然调用处理器理论上讲能够,但实际上往往受限制,除非父接口中的方法支持抛 Throwable 异常。那么如果在 invoke 方法中的确产生了接口方法声明中不支持的异常,那将如何呢?放心,Java 动态代理类已经为我们设计好了解决方法:它将会抛出 UndeclaredThrowableException 异常。这个异常是一个 RuntimeException 类型,所以不会引起编译错误。通过该异常的 getCause 方法,还可以获得原来那个不受支持的异常对象,以便于错误诊断。 回页首 代码是最好的老师 机制和特点都介绍过了,接下来让我们通过源代码来了解一下 Proxy 到底是如何实现的。 首先记住 Proxy 的几个重要的静态变量: 清单 5. Proxy 的重要静态变量 // 映射表:用于维护类装载器对象到其对应的代理类缓存 private static Map loaderToCache = new WeakHashMap(); // 标记:用于标记一个动态代理类正在被创建中 private static Object pendingGenerationMarker = new Object(); // 同步表:记录已经被创建的动态代理类类型,主要被方法 isProxyClass 进行相关的判断 private static Map proxyClasses = Collections.synchronizedMap(new WeakHashMap()); // 关联的调用处理器引用 protected InvocationHandler h; 然后,来看一下 Proxy 的构造方法: 清单 6. Proxy 构造方法 // 由于 Proxy 内部从不直接调用构造函数,所以 private 类型意味着禁止任何调用 private Proxy() {} // 由于 Proxy 内部从不直接调用构造函数,所以 protected 意味着只有子类可以调用 protected Proxy(InvocationHandler h) {this.h = h;} 接着,可以快速浏览一下 newProxyInstance 方法,因为其相当简单: 清单 7. Proxy 静态方法 newProxyInstance public static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h) throws IllegalArgumentException { // 检查 h 不为空,否则抛异常 if (h == null) { throw new NullPointerException(); } // 获得与制定类装载器和一组接口相关的代理类类型对象 Class cl = getProxyClass(loader, interfaces); // 通过反射获取构造函数对象并生成代理类实例 try { Constructor cons = cl.getConstructor(constructorParams); return (Object) cons.newInstance(new Object[] { h }); } catch (NoSuchMethodException e) { throw new InternalError(e.toString()); } catch (IllegalAccessException e) { throw new InternalError(e.toString()); } catch (InstantiationException e) { throw new InternalError(e.toString()); } catch (InvocationTargetException e) { throw new InternalError(e.toString()); } } 由此可见,动态代理真正的关键是在 getProxyClass 方法,该方法负责为一组接口动态地生成代理类类型对象。在该方法内部,您将能看到 Proxy 内的各路英雄(静态变量)悉数登场。有点迫不及待了么?那就让我们一起走进 Proxy 最最神秘的殿堂去欣赏一番吧。该方法总共可以分为四个步骤: 对这组接口进行一定程度的安全检查,包括检查接口类对象是否对类装载器可见并且与类装载器所能识别的接口类对象是完全相同的,还会检查确保是 interface 类型而不是 class 类型。这个步骤通过一个循环来完成,检查通过后将会得到一个包含所有接口名称的字符串数组,记为String[] interfaceNames。总体上这部分实现比较直观,所以略去大部分代码,仅保留留如何判断某类或接口是否对特定类装载器可见的相关代码。清单 8. 通过 Class.forName 方法判接口的可见性 try { // 指定接口名字、类装载器对象,同时制定 initializeBoolean 为 false 表示无须初始化类 // 如果方法返回正常这表示可见,否则会抛出 ClassNotFoundException 异常表示不可见 interfaceClass = Class.forName(interfaceName, false, loader); } catch (ClassNotFoundException e) { } 从 loaderToCache 映射表中获取以类装载器对象为关键字所对应的缓存表,如果不存在就创建一个新的缓存表并更新到 loaderToCache。缓存表是一个 HashMap 实例,正常情况下它将存放键值对(接口名字列表,动态生成的代理类的类对象引用)。当代理类正在被创建时它会临时保存(接口名字列表,pendingGenerationMarker)。标记 pendingGenerationMarke 的作用是通知后续的同类请求(接口数组相同且组内接口排列顺序也相同)代理类正在被创建,请保持等待直至创建完成。清单 9. 缓存表的使用 do { // 以接口名字列表作为关键字获得对应 cache 值 Object value = cache.get(key); if (value instanceof Reference) { proxyClass = (Class) ((Reference) value).get(); } if (proxyClass != null) { // 如果已经创建,直接返回 return proxyClass; } else if (value == pendingGenerationMarker) { // 代理类正在被创建,保持等待 try { cache.wait(); } catch (InterruptedException e) { } // 等待被唤醒,继续循环并通过二次检查以确保创建完成,否则重新等待 continue; } else { // 标记代理类正在被创建 cache.put(key, pendingGenerationMarker); // break 跳出循环已进入创建过程 break; } while (true); 动态创建代理类的类对象。首先是确定代理类所在的包,其原则如前所述,如果都为 public 接口,则包名为空字符串表示顶层包;如果所有非 public 接口都在同一个包,则包名与这些接口的包名相同;如果有多个非 public 接口且不同包,则抛异常终止代理类的生成。确定了包后,就开始生成代理类的类名,同样如前所述按格式“$ProxyN”生成。类名也确定了,接下来就是见证奇迹的发生 —— 动态生成代理类:清单 10. 动态生成代理类 // 动态地生成代理类的字节码数组 byte[] proxyClassFile = ProxyGenerator.generateProxyClass( proxyName, interfaces); try { // 动态地定义新生成的代理类 proxyClass = defineClass0(loader, proxyName, proxyClassFile, 0, proxyClassFile.length); } catch (ClassFormatError e) { throw new IllegalArgumentException(e.toString()); } // 把生成的代理类的类对象记录进 proxyClasses 表 proxyClasses.put(proxyClass, null); 由此可见,所有的代码生成的工作都由神秘的 ProxyGenerator 所完成了,当你尝试去探索这个类时,你所能获得的信息仅仅是它位于并未公开的 sun.misc 包,有若干常量、变量和方法以完成这个神奇的代码生成的过程,但是 sun 并没有提供源代码以供研读。至于动态类的定义,则由 Proxy 的 native 静态方法 defineClass0 执行。 代码生成过程进入结尾部分,根据结果更新缓存表,如果成功则将代理类的类对象引用更新进缓存表,否则清楚缓存表中对应关键值,最后唤醒所有可能的正在等待的线程。 走完了以上四个步骤后,至此,所有的代理类生成细节都已介绍完毕,剩下的静态方法如 getInvocationHandler 和 isProxyClass 就显得如此的直观,只需通过查询相关变量就可以完成,所以对其的代码分析就省略了。 回页首 代理类实现推演 分析了 Proxy 类的源代码,相信在读者的脑海中会对 Java 动态代理机制形成一个更加清晰的理解,但是,当探索之旅在 sun.misc.ProxyGenerator 类处嘎然而止,所有的神秘都汇聚于此时,相信不少读者也会对这个 ProxyGenerator 类产生有类似的疑惑:它到底做了什么呢?它是如何生成动态代理类的代码的呢?诚然,这里也无法给出确切的答案。还是让我们带着这些疑惑,一起开始探索之旅吧。 事物往往不像其看起来的复杂,需要的是我们能够化繁为简,这样也许就能有更多拨云见日的机会。抛开所有想象中的未知而复杂的神秘因素,如果让我们用最简单的方法去实现一个代理类,唯一的要求是同样结合调用处理器实施方法的分派转发,您的第一反应将是什么呢?“听起来似乎并不是很复杂”。的确,掐指算算所涉及的工作无非包括几个反射调用,以及对原始类型数据的装箱或拆箱过程,其他的似乎都已经水到渠成。非常地好,让我们整理一下思绪,一起来完成一次完整的推演过程吧。 清单 11. 代理类中方法调用的分派转发推演实现 // 假设需代理接口 Simulator public interface Simulator { short simulate(int arg1, long arg2, String arg3) throws ExceptionA, ExceptionB; } // 假设代理类为 SimulatorProxy, 其类声明将如下 final public class SimulatorProxy implements Simulator { // 调用处理器对象的引用 protected InvocationHandler handler; // 以调用处理器为参数的构造函数 public SimulatorProxy(InvocationHandler handler){ this.handler = handler; } // 实现接口方法 simulate public short simulate(int arg1, long arg2, String arg3) throws ExceptionA, ExceptionB { // 第一步是获取 simulate 方法的 Method 对象 java.lang.reflect.Method method = null; try{ method = Simulator.class.getMethod( "simulate", new Class[] {int.class, long.class, String.class} ); } catch(Exception e) { // 异常处理 1(略) } // 第二步是调用 handler 的 invoke 方法分派转发方法调用 Object r = null; try { r = handler.invoke(this, method, // 对于原始类型参数需要进行装箱操作 new Object[] {new Integer(arg1), new Long(arg2), arg3}); }catch(Throwable e) { // 异常处理 2(略) } // 第三步是返回结果(返回类型是原始类型则需要进行拆箱操作) return ((Short)r).shortValue(); } } 模拟推演为了突出通用逻辑所以更多地关注正常流程,而淡化了错误处理,但在实际中错误处理同样非常重要。从以上的推演中我们可以得出一个非常通用的结构化流程:第一步从代理接口获取被调用的方法对象,第二步分派方法到调用处理器执行,第三步返回结果。在这之中,所有的信息都是可以已知的,比如接口名、方法名、参数类型、返回类型以及所需的装箱和拆箱操作,那么既然我们手工编写是如此,那又有什么理由不相信 ProxyGenerator 不会做类似的实现呢?至少这是一种比较可能的实现。 接下来让我们把注意力重新回到先前被淡化的错误处理上来。在异常处理 1 处,由于我们有理由确保所有的信息如接口名、方法名和参数类型都准确无误,所以这部分异常发生的概率基本为零,所以基本可以忽略。而异常处理 2 处,我们需要思考得更多一些。回想一下,接口方法可能声明支持一个异常列表,而调用处理器 invoke 方法又可能抛出与接口方法不支持的异常,再回想一下先前提及的 Java 动态代理的关于异常处理的特点,对于不支持的异常,必须抛 UndeclaredThrowableException 运行时异常。所以通过再次推演,我们可以得出一个更加清晰的异常处理 2 的情况: 清单 12. 细化的异常处理 2 Object r = null; try { r = handler.invoke(this, method, new Object[] {new Integer(arg1), new Long(arg2), arg3}); } catch( ExceptionA e) { // 接口方法支持 ExceptionA,可以抛出 throw e; } catch( ExceptionB e ) { // 接口方法支持 ExceptionB,可以抛出 throw e; } catch(Throwable e) { // 其他不支持的异常,一律抛 UndeclaredThrowableException throw new UndeclaredThrowableException(e); } 这样我们就完成了对动态代理类的推演实现。推演实现遵循了一个相对固定的模式,可以适用于任意定义的任何接口,而且代码生成所需的信息都是可知的,那么有理由相信即使是机器自动编写的代码也有可能延续这样的风格,至少可以保证这是可行的。 回页首 美中不足 诚然,Proxy 已经设计得非常优美,但是还是有一点点小小的遗憾之处,那就是它始终无法摆脱仅支持 interface 代理的桎梏,因为它的设计注定了这个遗憾。回想一下那些动态生成的代理类的继承关系图,它们已经注定有一个共同的父类叫 Proxy。Java 的继承机制注定了这些动态代理类们无法实现对 class 的动态代理,原因是多继承在 Java 中本质上就行不通。 有很多条理由,人们可以否定对 class 代理的必要性,但是同样有一些理由,相信支持 class 动态代理会更美好。接口和类的划分,本就不是很明显,只是到了 Java 中才变得如此的细化。如果只从方法的声明及是否被定义来考量,有一种两者的混合体,它的名字叫抽象类。实现对抽象类的动态代理,相信也有其内在的价值。此外,还有一些历史遗留的类,它们将因为没有实现任何接口而从此与动态代理永世无缘。如此种种,不得不说是一个小小的遗憾。 但是,不完美并不等于不伟大,伟大是一种本质,Java 动态代理就是佐例。 参考资料 “Dynamic Proxy Classes”:查看 Java 动态代理的相关文档。 “Introduction to Java Exception Handling”:介绍了如何处理 Java 异常。 “Java 理论与实践: 用动态代理进行修饰”(developerWorks,2005 年 9 月):动态代理工具 是 java.lang.reflect 包的一部分,在 JDK 1.3 版本中添加到 JDK,它允许程序创建 代理对象。本文中,作者介绍了几个用于动态代理的应用程序。 “利用动态代理的 Java 验证”(developerWorks,2004 年 9 月):本文向您展示动态代理如何让核心应用程序代码独立于验证例程,而只关注业务逻辑。 developerWorks Java 技术专区:数百篇关于 Java 编程各个方面的文章。 作者简介 王忠平,软件工程师,目前在 IBM 上海中国系统技术实验室任职。 何平,软件工程师,目前在 IBM 上海中国系统技术实验室任职。 ============================================================================== 本文转自被遗忘的博客园博客,原文链接:http://www.cnblogs.com/rollenholt/articles/2229184.html,如需转载请自行联系原作者

优秀的个人博客,低调大师

如何把安全扩展到云端

IT世界已迁移到云端。市场数据各异,但对云使用的估测显示,当今总体计算工作负载的20-25%,都运行在公共云环境中,未来5年这一数字还将增长至50%(高盛投资公司预测)。 公司企业开始在混合环境中运营,包括了公共云、私有云和虚拟化环境。对大多数公司而言,这意味着需要有能服务于该整体基础设施的安全控制措施。 就像边界防御不足以防护公司网络一样,云端工作负载也不是默认安全的。AWS共享责任模型将这一点表达得很清楚。 AWS照看着底层基础设施,但其客户依然要负责自身云端数据和应用的安全、合规及操作控制。这意味着,安全配置、漏洞管理和日志管理等基础控制,无论在云端还是在本地,都同样重要。 由于云端和本地两种环境中的控制方式不同,如果计划将工作负载迁往云端,你可能会面临一些挑战。 云基础设施与本地基础设施迥异。如果原本的安全和合规控制是为本地环境设计的,千万别假定它们在云端也能正常工作。比如说,可能缺乏对 亚马逊Linux或Docker容器等面向云的技术的支持。反之,也别假设为云设计的控制措施,能在本地环境工作良好。 如果你的控制措施不能支持两种环境,最终结果可能就是每种环境都要部署一套控制措施。多环境多控制情况下,不仅仅是部署,包括管理和报告都会很麻烦,时间伤不起。另外,如果各基础设施上数据收集不持续,监管空白也会出现。 另外一个难点在于,弹性计算环境的动态特性。弹性计算环境中,资产是按需求扩充的,随时可能上线和下线。你的安全控制要能适应这种云资产快速创建和销毁的需求。否则,可见性空白和错误就会随着主机的出现/消失而产生。 两家大型金融服务公司的实践操作展现了该如何克服此一难点。这两家公司均将重点放在了最小化新机器镜像接收和推出之间的时间差上。他们实现的控制可以在镜像被接收时自动建立基准线。后续的改变也是实时检测的,不留一点儿暴露窗口时间,确保持续遵从所有现行规则。 快速部署镜像的能力,即便只有几个小时,也能使其应用开发人员充分利用云技术那前所未有的灵活性,享受持续的防护和长期审计跟踪。 换句话说,确保你的基础控制支持你整个基础设施上的各种策略、操作系统、平台和技术。 考虑一下能做到下列几点的工具集: 监视本地和外部环境;以统一的管理和报告环境,跨本地和云网络应用同一套健壮的控制措施;动态上下线节点,确保弹性环境中的持续监测;本地策略和平台之外,还要增加对云策略和平台的支持;评估Docker容器之类的开发运维和面向云的技术;在所选择的环境中(如:AWS、Azure、VMWare等)轻松部署预固化的主机镜像。总之,可预见的将来,你可能需要防护本地和云端两种环境。但不是所有解决方案都能在两种环境之间正常工作,所以,别假定本地运作良好的解决方案也能在云端表现不错。 本文转自d1net(转载)

优秀的个人博客,低调大师

GreenDao系列之(3)我的扩展

GreenDao的不足 之前也提到过,greenDao有以下不足: greenDao Generator仍然有点笨 greenDao的DaoMaster对数据库的创建和更新比较笨拙,无法实现智能更新。虽然网上有一个叫做MigrationHelper的解决方案,但仍不够友好。 greenDao的Property支持的属性有限,不支持default、is null、unique 等属性 greenDao不支持Property更新,只支持整个对象的更新 由于精力有限,我只会对第2-4点进行改进。 我的改进 针对以上几点,进行了几点改进: 支持更多属性设置:如NOT NULL、UNIQUE 支持Index配置,定义Index就和定义Property一样简单 数据库自动化升级 数据库支持属性更新 同时,为了享有后面greenDao开源的维护的成果,我们在保持gree

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

用户登录
用户注册