Apache Commons:Lang3 包下,有对 数字字符串 的快捷操作方法:
- 判断字符串是否为 数字:NumberUtils.isCreatable()
- 判断字符串是否为 全数字:NumberUtils.isDigits()
Apache Commons:Lang3 包下,有对 数字字符串 的快捷操作方法:
Maven的多模块项目搭建还是比较方便的,结构清晰,模块依赖明确,很适合用来作为开发RPC的开发架构,我们开发的RPC起一个名字,因为大学一直酷爱魔兽,喜欢魔兽解说xiaoy,他有一个别名叫做laopopo,所以我就没多想,就起了一个名字叫做laopopo-rpc,名字蹩脚了一点,不过不重要,明朝开国皇帝朱元璋真名叫朱重八,老爸叫做朱五四,他依旧做了皇帝,所以英雄不问姓名~ 虽然我写的也不是英雄,个人兴趣~
appendReplacement(StringBuffer sb, String replacement)
将当前匹配子串替换为指定字符串,并且将替换后的子串以及其之前到上次匹配子串之后的字符串段添加到一个StringBuffer对象里,而
appendTail(StringBuffer sb) 方法则将最后一次匹配工作后剩余的字符串添加到一个StringBuffer对象里。
例如,有字符串 fatcatfatcatfat,假设既有正则表达式模式为"cat",第一次匹配后调用appendReplacement(sb, "dog"),那么这时StringBuffer sb的内容为fatdog,也就是fatcat中的cat被替换为dog并且与匹配子串前的内容加到sb里,而第二次匹配后调用 appendReplacement(sb, "dog"),那么sb的内容就变为fatdogfatdog,如果最后再调用一次 appendTail(sb),那么sb最终的内容将是 fatdogfatdogfat。
介绍注册中心的功能的小节,我们曾经说过,注册中心要有持久化的操作,将一些服务的审核信息放到硬盘上,这样做的原因就是因为我们所有的服务信息都是放在内存里面的,如果注册中心的实例宕掉,或者服务器因为某种原因停止的时候,这样某些服务的审核记录就无法找回,为了避免这样的问题,我们需要做的事情就是把这些服务审核信息定时刷盘,把这些信息保存到硬盘上去,然后每个注册中心服务启动的时候,去硬盘上去恢复这些信息,这样就可以规避这样的问题了
为什么要有引用计数器
Netty里四种主力的ByteBuf,其中UnpooledHeapByteBuf 底下的byte[]能够依赖JVM GC自然回收;而UnpooledDirectByteBuf底下是DirectByteBuffer,如 Java堆外内存扫盲贴 所述,除了等JVM GC,最好也能主动进行回收;而PooledHeapByteBuf 和 PooledDirectByteBuf,则必须要主动将用完的byte[]/ByteBuffer放回池里,否则内存就要爆掉。所以,Netty ByteBuf需要在JVM的GC机制之外,有自己的引用计数器和回收过程。
一下又回到了C的冰冷时代,自己malloc对象要自己free。 但和C时代又不完全一样,内有引用计数器,外有JVM的GC,情况更为复杂。
并发编程实践中,this引用逃逸("this"escape)是指对象还没有构造完成,它的this引用就被发布出去了。这是危及到线程安全的,因为其他线程有可能通过这个逸出的引用访问到“初始化了一半”的对象(partially-constructed object)。这样就会出现某些线程中看到该对象的状态是没初始化完的状态,而在另外一些线程看到的却是已经初始化完的状态,这种不一致性是不确定的,程序也会因此而产生一些无法预知的并发错误。在说明并发编程中如何避免this引用逸出之前,我们先看看一个对象是如何产生this引用逸出的。
static是java中非常重要的一个关键字,而且它的用法也很丰富,主要有四种用法:
slf4j与log4j联合使用
slf4j是什么?slf4j只是定义了一组日志接口,但并未提供任何实现,既然这样,为什么要用slf4j呢?log4j不是已经满足要求了吗?
是的,log4j满足了要求,但是,日志框架并不只有log4j一个,你喜欢用log4j,有的人可能更喜欢logback,有的人甚至用jdk自带的日志框架,这种情况下,如果你要依赖别人的jar,整个系统就用了两个日志框架,如果你依赖10个jar,每个jar用的日志框架都不同,岂不是一个工程用了10个日志框架,那就乱了!