??xml version="1.0" encoding="utf-8" standalone="yes"?>
记得老师是这么描q摩?dng)定?/span>
-“
计算片集成电(sh)路数量,?/span>
18
个月M?#8221;。听q之后,我顿时感到神奇。神的地Ҏ(gu)Q不能理解ؓ什么电(sh)脑电(sh)脑更新这么快。奇的地方,计算片既然物质,那么肯定有极限,芯片数量U不可能会成数学规律增长。因此,我对q个预言一直抱有怀疑的态度?/span>
针对q个理论Q世界芯片巨头 Intel 相当地认可,毕竟摩尔其h也是 Intel 创徏Z一。因此, Intel 芯片数量的规律非常脓(chung)q摩?dng)定律?/span>
在很大程度上Q硬件执行速度军_了计机的运行速度。那也就_摩尔定律也媄响着pȝq行效率。众所周知Q操作系l支持ƈ发执行,不过在单处理器,宏观上是q行 Q但微观上是串行。在q种情况下,q行实现则是?/span> CPU 轮询的方式来执行dQ在用户感知下,是不会觉得gq的。如?/span> CPU 处理的速度快Q因此, CPU 在Q务之间切换的旉p短,用户更加不会察觉?/span>
摩尔定律Q可谓是成也 Intel Q|?/span> Intel 。由于开发成本和物理极限{原因,单处理器遇到了瓶颈, 摩尔定律也宣告失效。新的时代来?/span> - 多处理器时代?/span>
W者却认ؓ摩尔定律是一?#8220;大忽(zhn)?#8221;Q无论是物理限制Q还是计机体系和脑力的局限性。正所谓英雄所见略同。不久前Q微软创始h - 盖茨兄弟Q也赞同q种观点 。同Ӟ Intel q些公司Qؓ了I补技术革命上面的憋Q把q种摩尔意识强如植入了民众的大脑Q这׃难解释,?/span> 2005 q有一个公司叫 AMD ?/span> Intel 多么的狼狈,其中最有威慑力应属?/span> x64 架构?/span>
无论摩尔定律留下了什么,多处理器时代已经来(f)?/span>
上一:1.基础 下一:1.2 多处理器时代
当打破养?#8220;话”Ӟ老百姓又“清醒”q来Q被媒体玩弄到无以复加地步。知识匮乏和不求甚解Q甚x疑精都不具备,能不成ؓ(zhn)剧吗?
攄IT领域Q结果发C是惊人的怼?/font>
C~程语言的发展,让这个行业的门槛来低。就语言发展角度而言Q这是一U必然趋ѝ从从业人员的素质而言Q注定了良莠不齐的现象。往往技术h员容易经不v“新技?#8221;?#8220;诱惑”Q不断学?fn)所谓新?#8220;技?#8221;。在Java领域Q恐怕没有h不知?#8220;SSH”框架的大名。框架成׃其作者,也成了一U文化。本Z为面试官Ӟ当问到请描述一下以前项目的架构QL能够听到cM于这L(fng){案-“pȝ采用SSH架构...”。也?dng)R试必?/font>SSHQ因此本人的历很隑引他人的眼球?/font>
当我W一眼看?font face="Times New Roman">SpringQ觉得它?yu)?#8220;玩具”Q这L(fng)aZ怼遭到Spring_丝的口诛笔伐。当你能够反向思考的Ӟ你的世界也会发生变化?/font>Springl我们带来了什么?依赖倒置Q不{同于零依赖。轻入性,不等于没有浸入性。系l拆?/font>SpringQ虽然能够保证源代码兼容性(~译时不会遇到问题)Q可是那L(fng)l等同于D废-留下了一堆没有关联对象。当Ӟ目的q不在于花大力气来批?/font>SpringQ毕竟存在即理由Q?/font>Springq是有其优点-良好地编E风格和丰富的类库等?/font>Struts?/font>Hibernate也如此。作Z业从业h员,讨论“谁是谁非”是没有意义的。分析用场景,才是有意义的Q前提是你必M解它的优~点Qƈ非迎合或奉承它,不要Z技术而技术?/font>
当你厌倦了框架的重复劳动(重复的编码工作和大量新型框架重复发明轮子Q,也许你更加关注于原理性的东西Q甚x实现l节。那么,本系列的文章很可能会适合你?/span>
当我们刚接触某个事物Ӟ們Q观察)它,怀疑(分析Q它Q定位它。兼听则明,偏听则暗?/span>
文章来源Q?a title="作者JavaEye Blog" target="_blank" >作者的JavaEye Blog?/strong>
1. 基础
1.1 摩尔定律
1.2 多处理器时代
1.2.1 对称多处理( Symmetric Multi-Processor, a.k.a SMPQ?br />
1.2.2 非对U多处理Q?ASymmetric Multi-Processor, a.k.a ASMPQ?br />
1.2.3 非统一内存讉KQ?a.k.a NUMAQ?br />
1.3 ׃n内存QShared MemoryQ?br />
1.4 CPU ~存
1.4.1 ~存一致性(Cache coherenceQ?br />
1.4.2 MESI协议QMESI protocolQ?br />
1.5 U程
1.5.1 hQSourceQ?br />
1.5.2 优势QAdvantagesQ?br />
1.5.3 cdQTypesQ?br />
1.5.4 模型QModelsQ?br />
1.5.5 实现QImplementationsQ?br />
1.5.6 安全QSecurityQ?br />
1.6 内存模型 (Memory Model)
1.6.1 可见性(VisibilityQ?br />
1.6.2 原子性(AtomicityQ?br />
1.6.3 序性(OrderQ?br />
1.7 互斥Q?Mutual ExclusionQ?br />
1.7.1 d同步Q?Blocking SynchronizationQ?br />
1.7.1.1 临界区(Critical SectionQ?br />
1.7.1.2 锁(LockQ?br />
1.7.1.2.1 cdQTypesQ?br />
1.7.1.2.1.1 自旋锁(Spinning LockQ?br />
1.7.1.2.1.2 标签锁(Ticket LockQ?br />
1.7.1.2.1.3 偏向锁(Biased LockQ?
1.7.1.2.2 数据库锁QDatabase LockQ?
1.7.1.2.2.1 消极?br />
1.7.1.2.2.2 乐观?br />
1.7.1.2.3 问题QProblems)
1.7.1.2.3.1 z锁QLive LockQ?br />
1.7.1.2.3.2 死锁QDead LockQ?br />
1.7.1.2.3.3 优先U倒置QPriority InversionQ?br />
1.7.1.2.3.4 其他QOthersQ?nbsp;
1.7.2 非阻塞同步(Non-Blocking SynchronizationQ?br />
1.7.2.1 Wait-free法
1.7.2.1.1 比较交换法QCompare-And-Swap, a.k.a CASQ?br />
1.7.2.1.2 q接加蝲/条g存储QLoad-link/Store-conditionalQ?br />
1.7.2.1.3 ABA问题
1.7.2.2 Lock-free
1.7.2.3 Obstruction-free
1.7.3 重进入(ReentrantQ?br />
1.7.4 监视器(MonitorQ?br />
1.7.4.1 {待和信PWait and SignalQ?br />
1.7.4.2 条g变量QCondition VariableQ?br />
1.7.5 信号灯(SemaphoreQ?br />
1.7.6 双检查锁QDouble-Checked Locking, a.k.a DCLQ?br />
1.8 内存栅栏QMemory Barrier/Fence)
1.9 一致性模型(Consistency ModelQ?br />
1.9.1 原子一致性( Atomic consistencyQ?br />
1.9.2 q箋一致性(Sequential ConsistencyQ?br />
1.9.3 因果一致性(Causal ConsistencyQ?nbsp;
1.9.4 释放一致性(Release ConsistencyQ?nbsp;
1.9.5 最l一致性(Eventual ConsistencyQ?br />
1.9.6 Delta一致性(Delta ConsistencyQ?nbsp;
1.9.7 ׃致性(Weak ConsistencyQ?nbsp;
1.10 q发控制QConcurrency ControlQ?br />
1.10.1 软g事务存储QSoftware Transactional Memory,a.k.a STMQ?br />
2. Java 基础
2.1 Java同步原语
2.1.1 synchronized关键?br />
2.1.2 volatile 关键?br />
2.1.3 CAS操作-AtomicX
2.2 Java内存模型
2.2.1 可见性(VisibilityQ?br />
2.2.2 原子性(AtomicityQ?br />
2.2.3 序性(OrderQ?br />
2.2.4 Happens-Before
2.3 java.lang.Thread
2.3.1 状态(StateQ?br />
2.3.2 启动-Thread.startҎ(gu)
2.3.3 弃用Thread.stop, Thread.suspend ?Thread.resumeҎ(gu)
2.3.4 l止Thread.interrupt和Thread.interruptedҎ(gu)
2.3.5 Thread.joinҎ(gu)
2.3.6 Object.wait/notifyҎ(gu)
2.3.7 Thread.waitҎ(gu)
3. Javaq发框架
3.1J.U.C框架
3.1.1 同步
3.1.1.1 核心-AbstractQueuedSynchronizer
3.1.1.2 重进入锁-ReentrantLock
3.1.1.3 重进入读写锁-ReentrantReadWriteLock
3.1.1.4 条g变量-Condition
3.1.1.5 新通知/信号机制-LockSupport
3.1.2 限制
3.1.2.1 CountDownLatch
3.1.2.2 CyclicBarrier
3.1.2.3 信号灯(SemaphoreQ?br />
3.1.3 原子操作
3.1.3.1 Atomic*c?br />
3.1.3.2 操作实现-sun.misc.Unsafe
3.1.4 U程安全集合
3.1.4.1 CopyOnWriteArrayList和CopyOnWriteArraySet
3.1.4.2 ConcurrentSkipListMap和ConcurrentSkipListSet
3.1.4.3 ConcurrentHashMap
3.1.4.4 ArrayBlockingQueue
3.1.4.5 LinkedBlockingQueue和ArrayBlockingDueue
3.1.4.5 PriorityBlockingQueue
3.1.5 U程?br />
3.1.5.1 Executor
3.1.5.2 ThreadPoolExecutor
3.1.5.3 Callable和Future
3.1.5.4 ScheduledExecutorService
3.1.5.5 Executors
4. JVMq发实现 **
4.1 U程QThreadQ实?br />
4.2 监视器(MonitorQ实?br />
4.3 可见性实?br />
4.4 原子性实?br />
4.5 序性实?br />
4.6 其他
说明Q?/strong>
1. 在标题后面带有符?#8220;*”Q代表这个内容可能有点于偏离主题。带?#8220;**”的内容,可能比较难以理解?/span>
2. ׃知识体系比较J杂Q组lv来比较宽难,因此目录l构很有可能不断地更新。该文章的Update部分或者标题也会同步更新?/span>
3.一旦章节的内容完结Q目录会x更新链接Q请大家留意?/span>
4.作者能力和学识有限Q如果读者还有更加感兴趣的议题,或者Q何错误、意见和Q不妨直接留a或者发邮g来讨论。如果能够合著的话,那是更加完美了?/span>
5.文章转蝲前,误pL章的作者?/span>
谢谢
QEOFQ?/p>