前面介绍了文件通道的读写操作,其中用到字节缓存ByteBuffer,它是位于通道内部的存储空间,也是通道唯一可用的存储形式.ByteBuffer有两种构建方式,一种是调用静态方法wrap,根据输入的字节数组生成对应的缓存对象:另一种是调用静态方法allocateDirect,根据输入的数值分配指定大小的空缓存.字节缓存又是一种特殊的存储空间,因为它可能会被多次读写,所以为了有效地控制读写操作,Java给它设计了下列五种概念:容量.当前限制量.当前位置.本次剩余空间.标记位置,分别说明如下:1.容…

前面介绍了多线程并发之时的资源抢占情况,以及利用同步.加锁.信号量等机制解决资源冲突问题,不过这些机制只适合同一资源的共享分配,并未涉及到某件事由的前因后果.日常生活中,经常存在两个前后关联的事务,像雇员和雇主这两个角色,他们之间的某些工作就带有因果关系.比如要等雇主接到了项目,雇员才有活干:又如每月末员工都等着老板发工资,这样才有钱逛街和吃大餐,此时员工的消费行为便依赖于老板的发薪水动作.如此看来,两个线程之间理应建立某种消息通路,每当线程A完成某个事项,就将完成标志通知线程B,线程B收到通知…

前面介绍了线程的基本用法,以及多线程并发的问题处理,但实际开发中往往存在许多性质相似的任务,比如批量发送消息.批量下载文件.批量进行交易等等.这些同类任务的处理流程一致,不存在资源共享问题,相互之间也不需要通信交互,总之每个任务都可以看作是单独的事务,仿佛流水线上的原材料经过一系列步骤加工之后变为成品.可要是开启分线程的话,得对每项任务都分别创建新线程并予以启动,且不说如何的费时费力,单说这批量操作有多少任务就要开启多少分线程,系统的有限资源禁不起这么多的线程同时过来折腾.就像工厂里的流水线,每…

前面介绍了普通线程池的用法,就大多数任务而言,它们对具体的执行时机并无特殊要求,最多是希望早点跑完早点出结果.不过对于需要定时执行的任务来说,它们要求在特定的时间点运行,并且往往不止运行一次,还要周期性地反复运行.由于普通线程池满足不了此类定时运行的需求,因此Java又提供了定时器线程池来实现定时与周期执行任务的功能.普通线程池的工具类名叫ExecutorService,定时器线程池的工具类则叫做ScheduledExecutorService,添加了Scheduled前缀,表示它是一种有计划的…

前面依次介绍了普通线程池和定时器线程池的用法,这两种线程池有个共同点,就是线程池的内部线程之间并无什么关联,然而某些情况下的各线程间存在着前因后果关系.譬如人口普查工作,大家都知道我国总人口为14亿左右,可是14亿的数目是怎么数出来呢?倘若只有一个人去统计,从小数到老都数不完.好比一个线程老牛破车干不了多少事情,既然如此,不妨多起一些线程呗.于是人口普查工作就由中央分解到各个省份,各省又分派到下面的市县,再由市县分派到更下面的街道或乡镇,每个街道和乡镇统计完本辖区内的人口数量后,分别上报给对应的…

前面介绍了同步与加锁两种并发处理机制,虽然加锁比起同步要灵活一些,但是加锁在某些高级场合依然力有未逮,包括但不限于下列几点:1.某块代码被加锁之后,对其它线程而言就处于繁忙状态,缺乏弹性的阈值范围:2.遇到被其它线程加锁的情况,当前线程要么一直等待,要么立即放弃,除了这两种反应之外,没有别的选择了:3.线程A加锁之后,只能由线程A解锁,要是线程A忘了解锁,那么被锁住的资源将无法释放,从而导致其它线程出现死锁的情况:有鉴于此,Java又设计了一种信号量工具Semaphore,试图从根本上解决加锁机…

前面介绍了如何通过线程同步来避免多线程并发的资源冲突问题,然而添加synchronized的方式只在简单场合够用,在一些高级场合就暴露出它的局限性,包括但不限于下列几点:1.synchronized必须用于修饰方法或者代码块,也就是一定会有花括号把需要同步的代码给包裹起来.这样的话,花括号内外的变量交互比较麻烦,特别是同步代码块,多出来的花括号硬生生把原来的代码隔离开,只好通过局部变量来传递数值.2.synchronized的同步方式很傻,一旦同步方法/代码块被某个线程执行,其它线程到了这里就必…

多个线程一起办事固然能够加快处理速度,但是也带来一个问题:两个线程同时争抢某个资源时该怎么办?看来资源共享的另一面便是资源冲突,正所谓鱼与熊掌不可兼得,系统岂能让多线程这项技术专占好处?果然是有利必有弊,且看之前演示售票任务时候的多线程操作,具体代码如下所示: // 多个线程同时操作某个资源,可能会产生冲突 private static void testConflict() { // 创建一个售票任务 Runnable seller = new Runnable() { private Int…

前面介绍了JSON格式的报文解析,虽然json串短小精悍,也能有效表达层次结构,但是每个元素只能找到对应的元素值,不能体现更丰富的样式特征.比如某个元素除了要传输它的字符串文本,还想传输该文本的类型.字体大小.字体颜色等特征,且这些额外的风格样式与业务逻辑无关,自然不适合为它们单独设立参数字段.倘若采用JSON格式定义包括样式特征在内的文本元素,要么摒弃风格样式这种附加属性,要么将风格样式单列为专门的字段参数,然而不管哪种做法,都未能妥善解决附加属性的表达问题.可见轻量级的JSON格式依然存在力…

不管是AWT还是Swing,都把选择框分成两类:复选框和单选按钮,这两类控件无论是外观上还是功能上均有显著差异.例如,在外观方面,复选框是在方框内打勾,而单选按钮是在圆圈内画圆点:在功能方面,复选框允许多选,而同组的单选按钮只能选择其中一个.然而AWT的复选框和单选按钮统统采用Checkbox类型,区别之处在于是否加入了单选组CheckboxGroup.这不可避免又带来困惑,同样是Checkbox类型,代码该如何区分某个选择框到底是复选框还是单选按钮?显然AWT的控件设计很不合理,非常容易引起混…