《分布式Java应用:基础与实践》的封面和目录

标签: 书:分布式Java应用 分布式Java应用 | 发表时间:2010-05-21 14:09 | 作者:bluedavy 亦农
出处:http://blog.bluedavy.com

封面:

目录如下:
第1章 分布式Java应用 1
1.1 基于消息方式实现系统间的通信 3
1.1.1 基于Java自身技术实现消息方式的系统间通信 3
1.1.2 基于开源框架实现消息方式的系统间通信 10
1.2 基于远程调用方式实现系统间的通信 14
1.2.1 基于Java自身技术实现远程调用方式的系统间通信 14
1.2.2 基于开源框架实现远程调用方式的系统间通信 17
第2章 大型分布式Java应用与SOA 23
2.1 基于SCA实现SOA平台 26
2.2 基于ESB实现SOA平台 29
2.3 基于Tuscany实现SOA平台 30
2.4 基于Mule实现SOA平台 34
第3章 深入理解JVM 39
3.1 Java代码的执行机制 40
3.1.1 Java源码编译机制 41
3.1.2 类加载机制 44
3.1.3 类执行机制 49
3.2 JVM内存管理 63
3.2.1 内存空间 63
3.2.2 内存分配 65
3.2.3 内存回收 66
3.2.4 JVM内存状况查看方法和分析工具 92
3.3 JVM线程资源同步及交互机制 100
3.3.1 线程资源同步机制 100
3.3.2 线程交互机制 104
3.3.3 线程状态及分析 105
第4章 分布式应用与Sun JDK类库 111
4.1 集合包 112
4.1.1 ArrayList 113
4.1.2 LinkedList 116
4.1.3 Vector 117
4.1.4 Stack 118
4.1.5 HashSet 119
4.1.6 TreeSet 120
4.1.7 HashMap 120
4.1.8 TreeMap 123
4.1.9 性能测试 124
4.1.10 小结 138
4.2 并发包(java.util.concurrent) 138
4.2.1 ConcurrentHashMap 139
4.2.2 CopyOnWriteArrayList 145
4.2.3 CopyOnWriteArraySet 149
4.2.4 ArrayBlockingQueue 149
4.2.5 AtomicInteger 151
4.2.6 ThreadPoolExecutor 153
4.2.7 Executors 157
4.2.8 FutureTask 158
4.2.9 Semaphore 161
4.2.10 CountDownLatch 162
4.2.11 CyclicBarrier 163
4.2.12 ReentrantLock 164
4.2.13 Condition 164
4.2.14 ReentrantReadWriteLock 165
4.3 序列化/反序列化 167
4.3.1 序列化 167
4.3.2 反序列化 170
第5章 性能调优 173
5.1 寻找性能瓶颈 175
5.1.1 CPU消耗分析 175
5.1.2 文件IO消耗分析 182
5.1.3 网络IO消耗分析 186
5.1.4 内存消耗分析 187
5.1.5 程序执行慢原因分析 191
5.2 调优 192
5.2.1 JVM调优 192
5.2.2 程序调优 202
5.2.5 对于资源消耗不多,但程序执行慢的情况 214
第6章 构建高可用的系统 227
6.1 避免系统中出现单点 228
6.1.1 负载均衡技术 228
6.1.2 热备 236
6.2 提高应用自身的可用性 238
6.2.1 尽可能地避免故障 239
6.2.2 及时发现故障 246
6.2.3 及时处理故障 248
6.2.4 访问量及数据量不断上涨的应对策略 249
第7章 构建可伸缩的系统 251
7.1 垂直伸缩 252
7.1.1 支撑高访问量 252
7.1.2 支撑大数据量 254
7.1.3 提升计算能力 254
7.2 水平伸缩 254
7.2.1 支撑高访问量 254
7.2.2 支撑大数据量 264
7.2.3 提升计算能力 266

相关 [分布 java 应用] 推荐:

《分布式Java应用:基础与实践》的封面和目录

- 亦农 - BlueDavy之技术blog
第1章 分布式Java应用. 1.1 基于消息方式实现系统间的通信. 1.1.1 基于Java自身技术实现消息方式的系统间通信. 1.1.2 基于开源框架实现消息方式的系统间通信. 1.2 基于远程调用方式实现系统间的通信. 1.2.1 基于Java自身技术实现远程调用方式的系统间通信.

Java应用运维

- - BlueDavy之技术blog
对于互联网产品或长期运行的产品而言,运维工作非常重要,尤其是在产品复杂了以后,在这篇blog中就来说下Java应用的运维工作(ps:虽然看起来各种语言做的系统的运维工作都差不多,但细节上还是会有很多不同,so本文还是只讲Java的). 苦逼的码农按照需求开发好了一个全新的Java Web应用,该发布上线给用户用了,要把一个Java Web应用发布上线,首先需要搭建运行的环境,运行的环境需要有JDK、APPServer,在已经装好了os的机器上装上JDK和APPServer,开发好的Java Web应用可以用maven直接打成war或ear,将这个打好的包scp或其他方式到目标机器上,准备妥当,就差启动了.

Java线程池应用

- - CSDN博客架构设计推荐文章
1.减少了创建和销毁线程的次数,每个工作线程都可以被重复利用,可执行多个任务. 2.可以根据系统的承受能力,调整线程池中工作线线程的数目,防止因为消耗过多的内存,而把服务器累趴下(每个线程需要大约1MB内存,线程开的越多,消耗的内存也就越大,最后死机). Java里面线程池的顶级接口是Executor,但是严格意义上讲Executor并不是一个线程池,而只是一个执行线程的工具.

Java 应用一般架构

- - SegmentFault 最新的文章
原文地址: https://blog.coding.net/blog/General-architecture-for-Java-applications. 当我们架设一个系统的时候通常需要考虑到如何与其他系统交互,所以我们首先需要知道各种系统之间是如何交互的,使用何种技术实现. 现在我们常见的不同系统不同语言之间的交互使用WebService,Http请求.

xssProject在java web项目中应用

- - Java - 编程语言 - ITeye博客
1.项目引入xssProtect-0.1.jar、antlr-3.0.1.jar、antlr-runtime-3.0.1.jar包. * 覆盖getParameter方法,将参数名和参数值都做xss过滤. * 如果需要获得原始的值,则通过super.getParameterValues(name)来获取
.

使用Gradle构建Java Web应用(译)

- - BlogJava-首页技术区
使用Gradle构建Java Web应用. 本文是发布在 java.net上的一篇摘自于一书中的 节选,介绍了使用 Gradle构建Java Web应用的过程. 刚刚接触Gradle,看到了这篇小文,随手译了出来:-) (2014.01.23最后更新). 在职业生涯和私人生活中,我们中间的许多人要同时管理多个项目.

Java-了解注解及其应用

- - BlogJava-qileilove
  注解就是一种标记,在程序中加了注解就等于加了标记,没加,就没有标记. java编译器、开发工具或是其他程序可以通过反射技术了解你的类或各种元素是否有标记,有什么标记就做什么. 比如:子类重写父类的方法,方法上必须有@override标记;若一个方法已过时不用了,就该方法添加注.   解@Deprecated,调用者反射时就明白这方法已过时.

消除Java应用中的Exception开销

- - 舒の随想日记
抛异常最大的消耗在于构造整个异常栈的过程,如果你的栈很深,特别是用了一些框架的话,这个开销基本是不可忽视的,之前做的一个优化显示当时应用中的一个异常使得整个应用的性能下降至少30%. 最大开销的地方在这里,当你去new一个Exception的时候,会调用父类Throwable的构造函数, Throwable的构造函数中会调用native的fillInStackTrace(),这个方法就会构造整个异常栈了.

JAVA 应用性能监控基础

- - Linux - 操作系统 - ITeye博客
       这里简单介绍了JAVA 应用程序部署linux 服务器上的一些常用监控信息,虽然现在很多自动化监控的东西,但是一些基本的东西,我们还是需要了解.        1.我习惯性先看看 CPU 和内存的使用情况,做一个简单的关注.           命令:top 可以关注运行状态.           命令:大写P:按CPU 使用排序,大写M:按内存使用排序,小写c:详细显示应用       .

Java应用线上排查总结

- - arccode
本文总结了一些常见的线上应急现象和对应排查步骤和工具. 分享的主要目的是想让对线上问题接触少的同学有个预先认知,免得在遇到实际问题时手忙脚乱. 毕竟作者自己也是从手忙脚乱时走过来的. 在线上应急过程中要记住,只有一个总体目标: 尽快恢复服务,消除影响. 不管处于应急的哪个阶段,我们首先必须想到的是恢复问题,恢复问题不一定能够定位问题,也不一定有完美的解决方案,也许是通过经验判断,也许是预设开关等,但都可能让我们达到快速恢复的目的,然后 保留部分现场,再去定位问题、解决问题和复盘.