1, 保证线程安全的三种方法:
a, 不要跨线程访问共享变量
b, 使共享变量是final类型的
c, 将共享变量的操作加上同步
2, 一开始就将类设计成线程安全的, 比在后期重新修复它,更容易.
3, 编写多线程程序, 首先保证它是正确的,其次再考虑性能.
4, 无状态或只读对象永远是线程安全的.
5, 不要将一个共享变量裸露在多线程环境下(无同步或不可变性保护)
6, 多线程环境下的延迟加载需要同步的保护, 因为延迟加载会造成对象重复实例化
7, 对于volatile声明的数值类型变量进行运算, 往往是不安全的(volatile只能保证可见性,不能保证原子性).
详见volatile原理与技巧中, 脏数据问题讨论.
8, 当一个线程请求获得它自己占有的锁时(同一把锁的嵌套使用), 我们称该锁为可重入锁.
在jdk1.5并发包中, 提供了可重入锁的java实现-ReentrantLock.
9, 每个共享变量,都应该由一个唯一确定的锁保护.
创建与变量相同数目的ReentrantLock, 使他们负责每个变量的线程安全.
10,虽然缩小同步块的范围, 可以提升系统性能.
但在保证原子性的情况下, 不可将原子操作分解成多个synchronized块.
11, 在没有同步的情况下, 编译器与处理器运行时的指令执行顺序可能完全出乎意料.
原因是, 编译器或处理器为了优化自身执行效率, 而对指令进行了的重排序(reordering).
12, 当一个线程在没有同步的情况下读取变量, 它可能会得到一个过期值, 但是至少它可以看到那个
线程在当时设定的一个真实数值. 而不是凭空而来的值. 这种安全保证, 称之为最低限的安全性(out-of-thin-air safety)
在开发并发应用程序时, 有时为了大幅度提高系统的吞吐量与性能, 会采用这种无保障的做法.
但是针对, 数值的运算, 仍旧是被否决的.
13, volatile变量,只能保证可见性, 无法保证原子性.
详见 volatile原理与技巧
14, 某些耗时较长的网络操作或IO, 确保执行时, 不要占有锁.
15, 发布(publish)对象, 指的是使它能够被当前范围之外的代码所使用.(引用传递)
对象逸出(escape), 指的是一个对象在尚未准备好时将它发布.
原则: 为防止逸出, 对象必须要被完全构造完后,&
一个软件设计的好坏，我想很大程度上取决于它的整体架构，而这个整体架构其实就是你对整个宏观商业业务的抽象框架，当代表业务逻辑的高层抽象层结构 合理时，你底层的具体实现需要考虑的就仅仅是一些算法和一些具体的业务实现了。当你需要再开发另一个相近的项目时，你以前的抽象层说不定还可以再次利用 呢，面对对象的设计 ......
1. 总体设计
1.1 基本设计概念和处理流程
1.1.1 程序划分
主要分为服务端和客户端两个部分。
客户端部分又分为同步与异步两种模式。
1.1.2 处理流程描述
JAVA版接口平台主要实现与外部接口的服务端和客户端的通� ......
