前面提到URL尾巴支持添加请求参数,具体格式形如“参数A名称=A参数值&参数B名称=B参数值”,可是这种格式只能传递简单的键值对信息,不能传递结构化数据,也无法传递数组形式的参数,因而它不适用于需要输入复杂参数的场合.为此人们发明了一种轻量级的数据交换格式JSON,它的数据格式完全独立于编程语言,不但能够表达寻常的键值对信息,还支持表达数组形式的各类参数,从而满足了复杂参数的传输要求.不过Java的开发包并未提供相应的工具来处理JSON串,为此我们需要在工程中添加第三方JSON解析库,常见的js…

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

前面介绍了线程的几种运行方式,不管哪种方式,一旦调用了线程实例的start方法,都会立即启动线程的事务处理.然而某些业务场景在事务执行时间方面有特殊需求,例如期望延迟若干时间之后才开始事务运行,又如期望每隔若干时间依次启动事务处理,如此种种都要求在指定的时间才能启动线程任务,也就是俗称的定时功能.有别于一般的线程,Java为定时功能设计了专门的定时任务TimerTask,以及定时器Timer.其中TimerTask用来描述时刻到达后的事务处理,而Timer用来调度定时任务,包括何时启动定时任务.…

前面介绍了Lambda表达式的用法,从实践中发现它确实极大地方便了开发者,然而不管是匿名内部类还是Lambda表达式,所举的例子都离不开各类数组的排序方法,倘使Lambda表达式仅能用于sort方法,无疑限制了它的应用范围.那么除了sort方法,还有哪些场景能够将Lambda表达式派上用场呢?既然匿名内部类与Lambda表达式都依附于某种接口,追根究底,就得好好研究一下这种接口的特别之处.关于排序方法sort的第二个输入参数,原本定义的参数类型是比较器Comparator,可是这个比较器真正有用…

前面介绍while循环时,有个名叫year的整型变量频繁出现,并且它是控制循环进出的关键要素.不管哪一种while写法,都存在三处与year有关的操作,分别是“year = 0”.“year<limit”.“year++”.第一个“year = 0”用来给该变量初始赋值,第二个“year<limit”则为是否退出循环的判断条件,第三个“year++”用于该变量的自增操作.这三处语句结合起来,方能实现循环的有限次数处理,而非无限次的运转.换句话说,要想实现一个标准的循环结构,就必须具备上述的三种…

现将本博客的Java学习文章整理成以下笔记目录,方便查阅. 第一章 初识JavaJava开发笔记(一)第一个Java程序Java开发笔记(二)Java工程的帝国区划Java开发笔记(三)Java帝国的特种官吏Java开发笔记(四)Java帝国的度量衡 第二章 数值变量Java开发笔记(五)数值变量的类型Java开发笔记(六)特殊数字的表达Java开发笔记(七)强制类型转换的风险 第三章 算术运算Java开发笔记(八)五种算术运算符Java开发笔记(九)赋值运算符及其演化Java开发笔记(十)一元…

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

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

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

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