Netty

练习代码： 练习代码： 1 //这条语句说明这个Java文件在demo的包下 2 package demo1; 3 /** 4 * 5 * @author 王兴平 6 * 这个是第一个hello world 案例 7 * 这个注释是文本注释 8 * 注释内容是不会编译的，编译器会忽略其存在 9 * 10 */ 11 // 这是一个单行注释 现在用它描述个语句的功能 12 /* 13 * 这是多行注释 14 * 用它来描述内的工能的详细介绍 15 * 或者实现步骤 16 */ 17 /* 18 * 实现步骤： 19 * 1.定义一个类 class 20 * 2.编写程序执行的入口方法，main主方法 21 * 3.通过输出语句System.out.println()将信息”HelloWorld!”打印在控制台上 22 */ 23 24 //这条语句说明这个类的名字注意要和文件明相同 25 public class Helloworld { 26 //这是一个主方法程序执行的入口 27 public static void main(String[] args) { 28 //这是一条控制台输出语句 29 System.out.println("Hello World!"); 30 } 31 } 1 package demo2; 2 /** 3 * 4 * @author 王兴平 5

什么是增强for循环 增强for循环是一种简单模式的for循环，为了方便数组和集合的遍历而存在。 int [ ] arr = new int [ ] { 1 , 2 , 3 , 4 , 5 , 6 } ; for ( int a : arr ) { System . out . println ( a ) ; } ArrayList < Integer > list = new ArrayList ( ) ; list . add ( 1 ) ; list . add ( 2 ) ; list . add ( 3 ) ; list . add ( 4 ) ; list . add ( 5 ) ; list . add ( 6 ) ; for ( int i : list ) { System . out . println ( i ) ; } //加入Java开发交流君样：756584822一起吹水聊天 增强for循环的原理 对于集合的遍历，增强for循环其实内部是通过迭代器实现的，可以做一个简单的验证，我们知道在迭代器中，迭代的时候不允许修改，不然会抛出ConcurrentModificationException异常，那我们不妨在增强型for循环中也尝试去修改集合中的对象，看是否抛出同样的异常。 ArrayList < Integer > list = new

在读很多并发文章中，会提及各种各样锁如公平锁，乐观锁等等，这篇文章介绍各种锁的分类。介绍的内容如下： 公平锁/非公平锁 可重入锁 独享锁/共享锁 互斥锁/读写锁 乐观锁/悲观锁 分段锁 偏向锁/轻量级锁/重量级锁 自旋锁 上面是很多锁的名词，这些分类并不是全是指锁的状态，有的指锁的特性，有的指锁的设计，下面总结的内容是对每个锁的名词进行一定的解释。 公平锁/非公平锁 公平锁是指多个线程按照申请锁的顺序来获取锁。 非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。 对于Java ReentrantLock而言，通过构造函数指定该锁是否是公平锁，默认是非公平锁。非公平锁的优点在于吞吐量比公平锁大。 对于Synchronized而言，也是一种非公平锁。由于其并不像ReentrantLock是通过AQS的来实现线程调度，所以并没有任何办法使其变成公平锁。 可重入锁 可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。说的有点抽象，下面会有一个代码的示例。 对于Java ReentrantLock而言, 他的名字就可以看出是一个可重入锁，其名字是Re entrant Lock重新进入锁。 对于Synchronized而言,也是一个可重入锁

RPC 模块是我最初研究 Seata 源码开始的地方，因此我对 Seata 的 RPC 模块有过一些深刻研究，在我研究了一番后，发现 RPC 模块中的代码需要进行优化，使得代码更加优雅，交互逻辑更加清晰易懂，本着 “ 让天下没有难懂的 RPC 通信代码 ” 的初衷，我开始了 RPC 模块的重构之路。 这里建议想要深入了解 Seata 交互细节的，不妨从 RPC 模块的源码入手，RPC 模块相当于 Seata 的中枢，Seata 所有的交互逻辑在 RPC 模块中表现得淋漓尽致。 这次 RPC 模块的重构将会使得 Seata 的中枢变得更加健壮和易于解读。 重构继承关系 在 Seata 的旧版本中，RPC 模块的整体结构有点混乱，尤其是在各个类的继承关系上，主要体现在： 直接在 Remoting 类继承 Netty Handler，使得 Remoting 类与 Netty Handler 处理逻辑耦合在一起。 客户端和服务端的 Reomting 类继承关系不统一。 RemotingClient 被 RpcClientBootstrap 实现，而 RemotingServer 却被 RpcServer 实现，没有一个独立的 ServerBootstrap，这个看起来关系非常混乱。 有些接口没必要抽取出来，比如 ClientMessageSender

本篇以Dubbo作为服务端为例. 当配置如下信息时 <dubbo:application name= "infuq-dubbo-provider" /> <dubbo:registry protocol= "zookeeper" address= "127.0.0.1:2181" check= "false" /> <dubbo:protocol name= "dubbo" port= "20880" threads= "200" /> <dubbo:service ref = "queryUserInfoFacade" interface = "com.infuq.facade.QueryUserInfoFacade" version= "1.0.0" /> <bean id= "queryUserInfoFacade" class = "com.infuq.facade.impl.QueryUserInfoFacadeImpl" /> Spring在启动的过程中,通过 DubboNamespaceHandler 解析上面的标签. 将每个标签与之对应的 BeanDefinition 注册到BeanFactory中. Spring再根据 BeanDefinition 生成对应的Bean实例. 上面的<dubbo:service />标签最终会生成对应的 ServiceBean 实例

一.Netty服务端启动过程 1.创建服务端Channel 2.初始化服务端Channel 3.注册Selector 4.端口绑定：我们分析源码的入口从端口绑定开始， ServerBootstrap 的 bind(int inetPort) 方法，实际上是 AbstractBootstrap 的 bind(int inetPort) 方法 --- ServerBootstrap继承了AbstractBootstrap。 二.分析服务端创建Channel的过程 (1)bind() 【分析入口，端口绑定】 在 bind() 方法中，有一个 doBind() 方法，处理端口绑定： public ChannelFuture bind(SocketAddress localAddress) { validate(); if (localAddress == null) { throw new NullPointerException("localAddress"); } return doBind(localAddress);// 实际绑定 } 在 doBind() 方法中，调用initAndRegister来处理初始化和注册： private ChannelFuture doBind(final SocketAddress localAddress) { final

上一篇文章讲的是mysql的基本操作，这一篇会有一点难以理解，本节主要内容mysql视图，存储过程，函数，事务，触发器，以及动态执行sql 视图view 视图是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。对其中所引用的基础表来说，视图的作用类似于筛选。定义视图的筛选可以来自当前或其它数据库的一个或多个表，或者其它视图。通过视图进行查询没有任何限制，通过它们进行数据修改时的限制也很少。视图是存储在数据库中的查询的SQL 语句，它主要出于两种原因：安全原因， 视图可以隐藏一些数据。 1、创建视图 --格式：CREATE VIEW 视图名称 AS SQL语句 CREATE VIEW v1 AS SELET nid, name FROM tab1 WHERE nid > 4 2、删除视图 --格式：DROP VIEW 视图名称 DROP VIEW v1 3、修改视图 -- 格式：ALTER VIEW 视图名称 AS SQL语句 ALTER VIEW v1 AS SELET A.nid,B. NAME FROM tab1 LEFT JOIN B ON A.id = B.nid LEFT JOIN C ON A.id = C.nid