实时操作系统（Real-time operating system, RTOS），又称即时操作系统，它会按照排序执行、管理系统资源，并为开发应用程序提供一致的基础。
实时操作系统与一般的操作系统相比，最大的特色就是“实时性”，如果有一个任务需要执行，实时操作系统会马上（在较短时间内）执行该任务，不会有较长的延时。这种特性保证了各个任务的及时执行。
设计实时操作系统的首要目标不是高的吞吐量，而是保证任务在特定时间内完成，因此衡量一个实时操作系统坚固性的重要指标，是系统从接收一个任务，到完成该任务所需的时间，其时间的变化称为抖动。可以依抖动将实时操作系统分为两种：硬实时操作系统及软实时操作系统，硬实时操作系统比软实时操作系统有更少的抖动：
实时操作系统与一般的操作系统有着不同的调度算法。普通的操作系统的调度器对于线程优先级等方面的处理更加灵活；而实时操作系统追求最小的中断延时（英语：Interrupt latency）和线程切换延时。
通常都会有最基础的内核，以及外加上去的模块，像是文件系统、网络协议堆栈和应用、设备驱动程序等模块。
RTOS的内核通常会有：调度器、对象、服务。
通常，实时操作系统分为两大类:
时间触发型设计往往比较严格地调度任务，具有更好的多任务处理能力。多个任务被不停地轮流调度，在宏观上，就相当于一个CPU同时执行多个任务。
在过去，CPU在切换任务时往往需要多个机器周期，在这段时间内，CPU不能处理其他任何任务。例如，一个20 MHz的摩托罗拉68000处理器（1980年代后期），在切换任务时需要花费20微秒。（相比之下，一个100 MHz的ARM架构的处理器（2008年之后的）只需要3微秒。）因此，早期的实时操作系统通过减少任务切换次数来避免消耗过多CPU时间。
在典型的设计中，一个任务有以下三种状态：
由于CPU在某个时间只能执行一个任务，大部分任务，在大部分时间，处于阻塞或待命状态。可能会有大量项目在待命列表里等待执行，这取决于系统所需的任务数量以及调度器的类型。
通常情况下，对于简单的时间触发式调度器来说，待命任务列表的数据结构的设计要尽可能缩短最坏情况下，程序在调度器关键部分的执行时间，以防止其他任务一直在待命列表中，无法及时执行。因此，在这种调度器中，应尽可能避免抢占式任务，甚至应该关闭调度器之外的所有中断。当然，待命任务列表的数据结构也应根据这个系统需要的最大任务数量做进一步的优化。
如果待命任务列表中的任务较多，双向链表是一个比较好的选择。如果待命任务列表通常包含少量任务，但偶尔会出现较多任务，任务应该根据优先级排序。这样一来，要寻找最高优先级的任务，就不必要在整个列表中一个一个地寻找。而插入任务需要从列表中的第一个任务开始，向后寻找，直到找到比要插入的任务优先级低的任务，然后插入到该任务之前；如果没有找到优先级更低的任务，就插入到任务列表末尾。
在寻找任务列表，准备插入任务的过程中，应该注意避免抢占。长的关键部分应分为多个小的部分分别执行。如果在寻找任务列表，要插入低优先级任务的时候，一个中断发生使高优先级任务进入待命状态，高优先级任务应该在低优先级任务被插入之前立刻被插入列表和执行。
在更先进的系统中，实时任务和许多非实时任务共享运算资源，这时候待命任务列表会变得很长。在这种系统中，待命任务列表可能不适合用链表的结构。
一些实时操作系统中常用的算法：
WinCE、VxWorks、μC/OS-Ⅱ等运用较广。Linux是作为通用操作系统开发的，其内核在实时处理能力上先天不足，部分网络开发社区将其经过改造能在一定程度上成为实时操作系统。
