YellowStar5

风物长宜放眼量

0%

这篇文章是我 2019 年写的年末小总结,稍加修改, 主要是回顾一下自己的成长历程。当然,如果对其他人有帮助,那就更好了。

1.有没有什么捷径? 大二下

我是 2016 年 6 月 1 号进冯大(Fenng)的小密圈,算到现在已经 2 年多了。说实话,刚开始进去的时候,老是在想有没有捷径,成功的秘诀之类的。在圈子里呆了一段时间发现,好像大多人都是一步步走,并没有什么奇技淫巧,一步登天。

2.学什么呢? 大三下

各个公众号,各个新闻,就连校园里,一天到晚都在云计算,大数据,机器学习,人工智能。

我要不要去学下?好吧,抵制不了诱惑,自己也不思考,看着也挺有趣,那就去试试呗。看了一段时间好像不太懂,数学基础不够,那些东西都不怎么会推导。你要是我读英文文档,调 API,跑起来不难,让我自己理解透彻改进,不行。

于是就在星球里面问冯大了,冯大回答说:“普通本科生,我一般的建议是打好基础。把基本功做好,别整天追热点,热点是追不完的”。看了冯大的回答,自己又不打算考研,就老老实实复习,先准备面试。冯大说的打基础,但当时还是没闹清楚基础要学到什么程度,一方面是懒,一方面是认知有限

阅读全文 »

1.同步的语义

下面的内容摘自JSR 133 FAQ:

Synchronization has several aspects. The most well-understood is mutual exclusion – only one thread can hold a monitor at once, so synchronizing on a monitor means that once one thread enters a synchronized block protected by a monitor, no other thread can enter a block protected by that monitor until the first thread exits the synchronized block.

同步有几个方面。最容易理解的是互斥 —— 只有一个线程可以立即持有一个监视器,因此在监视器上进行同步意味着一旦一个线程进入由一个监视器保护的同步块,则其他线程都不能进入该监视器保护的块,直到第一个线程退出同步块。

阅读全文 »

原文地址:https://wiki.openjdk.java.net/display/HotSpot/Synchronization

Synchronization and Object Locking (同步和对象锁定)

One of the major strengths of the Java programming language is its built-in support for multi-threaded programs. An object that is shared between multiple threads can be locked in order to synchronize its access. Java provides primitives to designate critical code regions, which act on a shared object and which may be executed only by one thread at a time. The first thread that enters the region locks the shared object. When a second thread is about to enter the same region, it must wait until the first thread has unlocked the object again.

Java 编程语言的主要优势之一是其对多线程程序的内置支持。 可以锁定在多个线程之间共享的对象,以便同步其访问。 Java 提供了用于指定关键代码区域的原语,这些关键代码区域作用于共享对象,并且可能一次只能由一个线程执行。 进入该区域的第一个线程将锁定共享对象。 当第二个线程即将进入同一区域时,它必须等待,直到第一个线程再次将对象解锁。

阅读全文 »

由于本人能力有限,如有错误,欢迎指出。
原文地址https://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
如果你喜欢原文那种板式的话,可以看这个https://yellowstar5.cn/direct/jsr-133-faq-chinese.html

What is a memory model, anyway? (无论如何,什么是内存模型?)

In multiprocessor systems, processors generally have one or more layers of memory cache, which improves performance both by speeding access to data (because the data is closer to the processor) and reducing traffic on the shared memory bus (because many memory operations can be satisfied by local caches.) Memory caches can improve performance tremendously, but they present a host of new challenges. What, for example, happens when two processors examine the same memory location at the same time? Under what conditions will they see the same value?

在多处理器系统中,处理器通常具有一层或多层内存高速缓存, 这可以通过加快对数据的访问速度 (因为数据更靠近处理器) 和减少共享内存总线上的通信量 (因为本地缓存可以满足许多内存操作。)来提高性能。内存缓存可以极大地提高性能,但是它们带来了许多新的挑战。 例如,当两个处理器同时检查相同的内存位置时会发生什么? 他们将在什么条件下看到相同的价值?

At the processor level, a memory model defines necessary and sufficient conditions for knowing that writes to memory by other processors are visible to the current processor, and writes by the current processor are visible to other processors. Some processors exhibit a strong memory model, where all processors see exactly the same value for any given memory location at all times. Other processors exhibit a weaker memory model, where special instructions, called memory barriers, are required to flush or invalidate the local processor cache in order to see writes made by other processors or make writes by this processor visible to others. These memory barriers are usually performed when lock and unlock actions are taken; they are invisible to programmers in a high level language.

在处理器级别,内存模型定义了必要条件和充分条件,以便知道其他处理器对内存的写操作对当前处理器可见,和当前处理器的写操作对其他处理器可见。 一些处理器表现出强大的内存模型,其中所有处理器始终在任何给定的内存位置看到完全相同的值。 其他处理器表现出较弱的内存模型,其中需要特殊的指令(称为内存屏障)来刷新或使本地处理器缓存无效, 以便该本地处理器看到其他处理器做出的写入或使该处理器的写入对其他处理器可见。 这些内存屏障通常在执行锁定和解锁操作时执行; 使用高级语言的程序员看不到它们。

阅读全文 »

由于本人能力有限,如有错误,烦请指出。
原文地址http://gee.cs.oswego.edu/dl/jmm/cookbook.html
我博客上中英对照版的地址https://yellowstar5.cn/direct/The%20JSR-133%20Cookbook-chinese.html

Preface: Over the 10+ years since this was initially written, many processor and language memory model specifications and issues have become clearer and better understood. And many have not. While this guide is maintained to remain accurate, it is incomplete about some of these evolving details. For more extensive coverage, see especially the work of Peter Sewell and the Cambridge Relaxed Memory Concurrency Group

前言: 自此指南最初编写以来已有十多年,许多处理器和语言内存模型规范和问题已经变得更加清晰和更好地被理解。 然而许多还没有。 尽管本指南一直被维护着以保持准确性,但关于一些不断发展的细节,此指南给出的内容并不完整。 有关更广泛的报道,尤其要参见 Peter Sewell 和 Cambridge Relaxed Memory Concurrency Group 的工作。

This is an unofficial guide to implementing the new Java Memory Model (JMM) specified by JSR-133 . It provides at most brief backgrounds about why various rules exist, instead concentrating on their consequences for compilers and JVMs with respect to instruction reorderings, multiprocessor barrier instructions, and atomic operations. It includes a set of recommended recipes for complying to JSR-133. This guide is “unofficial” because it includes interpretations of particular processor properties and specifications. We cannot guarantee that the intepretations are correct. Also, processor specifications and implementations may change over time.

这是实现由 JSR-133 规范的新 Java Memory Model (JMM) 的非官方指南。 它提供了有关为什么存在各种规则的最简短的背景,而不是专注于它们在指令重新排序,多处理器屏障指令和原子操作方面对编译器和JVM的影响。 它包括一组符合 JSR-133 的推荐食谱。 本指南是“非官方的”,因为它包含对特定处理器属性和规范的解释。 我们不能保证解释是正确的。 此外,处理器规范和实现可能会随时间而变化。

Reorderings (重排序)

For a compiler writer, the JMM mainly consists of rules disallowing reorderings of certain instructions that access fields (where “fields” include array elements) as well as monitors (locks).

对于一个编译器编写者来说,JMM主要由禁止对访问字段(其中“字段”包括数组元素)和监视器(锁)的某些指令进行重排序的规则组成。

Volatiles and Monitors (volatile 和监视器)

The main JMM rules for volatiles and monitors can be viewed as a matrix with cells indicating that you cannot reorder instructions associated with particular sequences of bytecodes. This table is not itself the JMM specification; it is just a useful way of viewing its main consequences for compilers and runtime systems.
可以将 volatile 和监视器的主要 JMM 规则视为带有单元格的矩阵,其中单元格指示了你无法对与特定字节码序列相关的指令进行重排序。 这个表格本身不是 JMM 规范; 它只是查看其对编译器和运行时系统的主要影响的一种有用方法。
在这里插入图片描述

阅读全文 »