Answers:
/dev/shm是一个临时文件存储文件系统，即tmpfs，它使用RAM作为后备存储。它可以用作促进IPC的共享内存实现。
最近的2.6 Linux内核构建已开始以ramdisk的形式提供/ dev / shm作为共享内存，更具体地说，是一个世界可写目录，该目录以/ etc / default / tmpfs中定义的限制存储在内存中。 / dev / shm支持在内核配置文件中是完全可选的。 在Fedora和Ubuntu发行版中，默认情况下都包含它，在Pulseaudio应用程序中使用最广泛。 （已添加重点。）
/tmp是文件系统层级标准（Filesystem Hierarchy Standard）中定义的临时文件的位置，几乎所有的Unix和Linux发行版都紧随其后。
由于RAM比磁盘存储显著快，你可以使用/dev/shm，而不是/tmp对性能提升，如果你的过程是I / O密集型和广泛使用的临时文件。
要回答您的问题：不，您不能总是依靠/dev/shm在场，当然也不能依靠捆绑存储的机器。/tmp除非您有充分的理由使用，否则应该使用/dev/shm。
请记住，它/tmp可以是/文件系统的一部分，而不是单独的安装，因此可以根据需要增长。的大小/dev/shm受系统上过多的RAM限制，因此您更有可能在此文件系统上用完空间。
/dev/shm。/dev/shm是磁盘（交换）支持的内存（tmpfs）。/var/tmp是磁盘（磁盘文件系统）支持的内存（磁盘缓存）。实际上，性能大致相同（tmpfs略有优势，但不足以解决问题）。/tmp可能是tmpfs，取决于管理员的配置方式。没有充分的理由/dev/shm在您的脚本中使用。
/tmp则该位置为正常位置（带有$TMPDIR覆盖）。/tmp由交换，其他磁盘空间或什么都不做的选择是管理员的。
以tmpfs可能性的降序排列：
┌───────────┬──────────────┬────────────────┐
│ /dev/shm │ always tmpfs │ Linux specific │
├───────────┼──────────────┼────────────────┤
│ /tmp │ can be tmpfs │ FHS 1.0 │
├───────────┼──────────────┼────────────────┤
│ /var/tmp │ never tmpfs │ FHS 1.0 │
└───────────┴──────────────┴────────────────┘
由于您询问的是Linux特定的tmpfs挂载点，而不是一个可能是tmpfs 的可移植定义的目录（取决于您的sysadmin和发行版的默认设置），因此您的问题有两个方面，其他答案对此有不同的强调：
保守版（FHS惯例与常用惯例的混合）：
/tmp。/var/tmp大数据，可能难以适应在RAM中。/var/tmp的数据是有益的，保持在重新启动后（如高速缓存）。/dev/shm作为主叫的副作用shm_open()。预期的受众是无限地覆盖的有界缓冲区。因此，这适用于内容易失且不会很大的长寿命文件。mktemp程序使用TMPDIR环境变量。实用版：
使用/dev/shm时，重要的是要使用tmpfs的，/var/tmp当它是重要的是不要，否则/tmp。
fsync在tmpfs上不起作用。尽管您发现自己使用的是tmpfs（或eatmydata），但此syscall是（IO）性能（和闪存寿命，如果您对此很在意）的头号敌人）只是为了击败fsync，那么您（或该链中的其他开发人员）在做错事。这意味着针对您的目的对存储设备进行的事务处理不必要地精细化-您显然愿意跳过一些保存点以提高性能，因为您现在已经将它们全部破坏到极点-很少能做出最佳妥协。同样，在交易性能领域中，拥有SSD的一些最大好处是–与旋转磁盘可能需要的功率（7200 rpm = 120 Hz）相比，任何像样的SSD都将具有超凡脱俗的性能，如果没有其他访问，则更不用说闪存卡了，该闪存卡在该指标上有很大的不同（尤其是因为这是对顺序性能的折衷，这是它们通过例如SD卡等级评定的等级）。所以要当心
想听一个荒谬的故事吗？我的第一fsync课：我从事一项工作，涉及定期将一堆Sqlite数据库（称为测试用例）“升级”到不断变化的当前格式。“升级”框架将运行一堆脚本，每个脚本至少进行一个事务以升级一个数据库。当然，我并行升级了数据库（并行升级了8个数据库，因为我拥有强大的8核CPU）。但是，正如我发现的那样，没有任何并行化加速（而是一点点命中），因为该过程完全受IO约束。有趣的是，将升级框架包装在一个脚本中，该脚本将每个数据库复制到/dev/shm，然后在该数据库中进行升级，然后将其复制回磁盘，速度提高了100倍（并行8个）。作为奖励，PC 可用 在升级数据库时也是如此。
tmpfs的适当用法是为了避免不必要地写入易失性数据。有效地禁用写回，例如/proc/sys/vm/dirty_writeback_centisecs在常规文件系统上设置为infinity。
这与性能没有多大关系，如果没有此问题，则与滥用fsync相比，它的关注要小得多：写回超时决定了页面缓存内容之后磁盘内容的更新延迟，对于计算机而言，默认值为5秒是很长时间。 –应用程序可以在页面缓存中根据需要频繁地覆盖文件，但是磁盘上的内容仅每5秒更新一次。除非应用程序使用fsync强制通过它。考虑一下应用程序这次可以输出一个小文件多少次，并且您知道为什么同步每个单个文件会带来更大的问题。
fsync当然要强制使用。保持冷数据。您可能会倾向于认为从交换中提供文件与普通文件系统一样有效，但是有两个原因导致它不起作用：
mount -t tmpfs "jarno is great" /mnt/jarno如果您愿意，可以！第三，默认大小是RAM的一半–我敢打赌，您有4GiB RAM。
好的，这就是现实。
tmpfs和普通文件系统都是磁盘上的内存高速缓存。
tmpfs使用内存和交换空间作为后备存储文件系统使用特定的磁盘区域，文件系统的大小都不受限制，如果内存小于GB的机器上可能有200GB的tmpfs您有足够的交换空间。
区别在于何时将数据写入磁盘。对于tmpfs，仅在内存太满或不太可能很快使用数据时才写入数据。OTOH大多数正常的Linux文件系统都被设计为在磁盘上始终具有或多或少一致的数据集，因此，如果用户拔出插头，他们就不会失去一切。
就我个人而言，我习惯了不会崩溃的操作系统和UPS系统（例如：笔记本电脑电池），因此我认为ext2 / 3文件系统的5-10秒检查点间隔太偏执。ext4文件系统最好具有10分钟的检查点，但它会将用户数据视为第二类并且不对其进行保护。（ext3相同，但是由于5秒检查点而没有引起注意）
这种频繁的检查点意味着，即使对于/ tmp，不必要的数据也不断被写入磁盘。
因此，结果是您需要创建与/ tmp一样大的交换空间（即使必须创建一个swapfile），并使用该空间将所需大小的tmpfs挂载到/ tmp上。
切勿使用/ dev / shm。
除非您将它用于很小的（可能是经过mmap处理的）IPC文件，并且您确定它存在（这不是标准），并且计算机具有足够的内存+可用交换空间。
将/ tmp /用于临时文件。需要共享内存（即通过文件进行进程间通信）时，请使用/ dev / shm /。
您可以依靠/ tmp /在那里，但是/ dev / shm /是相对较新的Linux专用。
1>/dev/null 2>&1。我会执行数千次，因此tmpfs会很好。但是如果我发布脚本，我不能依赖于tmpfs，/tmp因为我认为它并不常见。如果更常见，/dev/shm那么对我来说更好。但是，我正在寻找有关可移植性的指南
另一个应该使用/ dev / shm（对于Linux 2.6及更高版本）的时间是，您需要保证的tmpfs文件系统，因为您不知道是否可以写入磁盘。
我熟悉的监视系统在构建报告以提交到中央服务器时需要写出临时文件。在实践中，更有可能阻止某些东西写入文件系统（磁盘空间不足或潜在的RAID故障使系统进入硬件只读模式），但您仍然可以保持警惕而不是什么东西使所有可用内存增加，从而使tmpfs变得不可用（并且盒子不会死）。在这样的情况下，监视系统将更喜欢写到RAM，以便潜在地能够发送有关磁盘已满或硬件已死/快死的警报。
在PERL中，任何机器（均运行Linux Mint）上至少有8GB的空间，我认为这是一个好习惯，即使用/ dev / shm
在其他语言中，并不是到处都有，为了避免网络传输的开始和停止（在客户端-服务器环境中在位于服务器上的文件本地工作），我将使用某种类型的批处理文件来复制将整个（300-900MB）文件一次存储到/ dev / shm，运行程序，将输出输出到/ dev / shm，将结果写回到服务器，然后从/ dev / shm删除
自然，如果我的RAM较少，则不会这样做。通常，/ dev / shm的内存文件系统读取的大小是可用RAM的一半。但是，RAM的常规使用是恒定的。因此，您实际上无法在2GB或更小的设备上执行此操作。为了将夸张的说法夸张，RAM中经常有一些东西，即使系统报告也不佳。
/dev/shm存在，如果存在则使用它，否则回退到/tmp。听起来不错吗？