应用云平台的可用性——从新浪SAE看云平台设计
云计算平台的可用性，相比传统互联网服务而言，更加复杂和困难，也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台，以及对云计算的用户提出了建议。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
关于实时Java的系列文章
作者 R.J. Lorimer 译者 张凯峰 发布于 2008年8月1日
该系列第一部分介绍了实时程序设计的概念，及其与Java的关系，并描述了应用标准Java运行时系统创建实时应用的障碍：
- 操作系统问题：调度延迟、时钟精度较低。
- 线程优先级问题：不可靠的线程优先级保证和优先级倒置。
- 类加载延迟。
- 垃圾回收延迟。
- 应用程序代码不符合实时要求。
- 系统中存在其它优先级较高的活动。
在一个真正的实时环境中，线程优先级是极其重要的，没有一个系统可以保证，所有的任务都能够准时完成。然而，一个实时系统能够确保的是，当有些任务即将超过最终时限时，可以先牺牲低优先级的任务来保障它的执行。Goetz和Eckstein接着提到Java实时系统规范的核心概念——实时线程：
RTSJ定义了至少28种优先权级别，并要求严格执行此规定。然而，正如本篇文章前面所说，RTSJ的实现依赖于支持多种优先权的实时操作系统，和高优先级线程抢占低优先级线程的能力。
此外，RTSJ可允许非实时和实时活动同时存在于一个Java应用中，对一个活动的时序保证程度依赖于活动所属线程类型：第一部分讲到的最后一个概念是，支持内存管理所做的各种扩展。由于与垃圾回收及对象分配相关的延迟的存在，三个内存区域被划分出来：java.lang.Thread或javax.realtime.RealtimeThread线程类型。
- 标准java.lang.Thread(JLT)线程用来支持非实时的活动。JLT线程可以应用Thread类定义的10种优先权级别，但是它们不适用于实时活动，因为不能够提供时序执行保证。
- RTSJ还定义了
javax.realtime.RealtimeThread(RTT)线程类型。RTTs可以利用RTSJ提供的强大的线程优先权支持，它的调度遵循运行直至阻塞(run-to-block)原则，而非按时间片运行原则。这就意味着，当有另外具有较高优先权的RTT出现时，调度程序会抢占该RTT。
- 标准堆(Standard heap)——与标准Java中的内存管理类似。
- 永久内存(Immortal memory)——必须由软件显式释放的内存。
- 作用域内存(Scoped memory)——具有不连续生命周期的内存，有固定大小。
引入RealtimeThread的扩展类——NoHeapRealtimeThread，以实时友好的方式辅助管理这些独特的内存区域：
RTSJ提供一个RTT的子类，称为然而，即使软件正在使用特定的内存区域，它的资源使用依然很容易受到内存其它非关键部分的GC的影响。由于这个原因，该系列文章的第二部分集中于和垃圾回收相关的问题，阐述了可用于实时Java系统的不同GC方法，然后介绍了Sun的商业实时Java系统：Java RTS。在第二部分中描述了四种垃圾回收算法：NoHeapRealtimeThread(NHRT)。该子类得实例可以避免由垃圾回收引起的不稳定情况。这个NHRT类是为硬实时(hard-real-time)活动所准备的。
为最大化可预测性，NHRTs不能访问垃圾回收堆，也不能操纵堆变量。否则，线程会遭遇GC暂停，这将导致任务错过运行时限。与此相反的是，NHRT可以更具预测性的方式使用作用域内存和永久内存特性分配内存。
- 基于工作的GC(Work-Based GC)——回收由对象分配触发。
- 基于时间的GC(Time-Based GC)——回收通过标准的时间箱划定界限。
- Henriksson's GC——在关键和非关键线程之间有所区别的基于工作的GC(Work-based GC)。
- Java RTS Real-Time GC (RTGC)——可以用在Java RTS中，更加灵活/细粒度的Henriksson's GC的扩展。
查看原文：Two-Part Series on Real-Time Java
译者 张凯峰 InfoQ中文站编辑，有多年软件开发和测试经验，热衷参与技术社区与技术传播。
没有回复
关注此讨论 回复