[算法]C语言实现 骑士旅游(递归)
2015-01-25 20:26
423 查看
1. In normal operation, Javadoc does not include the synchronized modifier in its output, and with good reason. The presence of the synchronized modifier in a method declaration is an implementation detail, not a part of its exported API. It does not reliably indicate that a method is thread-safe. The claim that the presence of the synchronized modifier is sufficient to document thread safety embodies the misconception that thread safety is an all-or-nothing property. In fact, there are several levels of thread safety. To enable safe concurrent use, a class must clearly document what level of thread safety it supports.
2. The following list summarizes levels of thread safety:
1) immutable—Instances of this class appear constant. No external synchronization is necessary.
2) unconditionally thread-safe—Instances of this class are mutable, but the class has sufficient internal synchronization that its instances can be used concurrently without the need for any external synchronization.
3) conditionally thread-safe—Like unconditionally thread-safe, except that some methods require external synchronization for safe concurrent use. Examples include the collections returned by the Collections.synchronized wrappers, whose iterators require external synchronization.
4) not thread-safe—Instances of this class are mutable. To use them concurrently, clients must surround each method invocation (or invocation sequence) with external synchronization of the clients’ choosing.
5) thread-hostile—This class is not safe for concurrent use even if all method invocations are surrounded by external synchronization. Thread hostility usually results from modifying static data without synchronization.
3. If an object represents a view on some other object, the client generally must synchronize on the backing object, so as to prevent its direct modification. For example, the documentation for Collections.synchronizedMap says this: It is imperative that the user manually synchronize on the returned map when iterating over any of its collection views:
4. If you write an unconditionally thread-safe class, consider using a private lock object in place of synchronized methods. This protects you against synchronization interference by clients and subclasses and gives you the flexibility to adopt a more sophisticated approach to concurrency control in a later release.
5. Every class should clearly document its thread safety properties with a carefully worded prose description or a thread safety annotation. The synchronized modifier plays no part in this documentation. Conditionally thread-safe classes must document which method invocation sequences require external synchronization, and which lock to acquire when executing these sequences.
2. The following list summarizes levels of thread safety:
1) immutable—Instances of this class appear constant. No external synchronization is necessary.
2) unconditionally thread-safe—Instances of this class are mutable, but the class has sufficient internal synchronization that its instances can be used concurrently without the need for any external synchronization.
3) conditionally thread-safe—Like unconditionally thread-safe, except that some methods require external synchronization for safe concurrent use. Examples include the collections returned by the Collections.synchronized wrappers, whose iterators require external synchronization.
4) not thread-safe—Instances of this class are mutable. To use them concurrently, clients must surround each method invocation (or invocation sequence) with external synchronization of the clients’ choosing.
5) thread-hostile—This class is not safe for concurrent use even if all method invocations are surrounded by external synchronization. Thread hostility usually results from modifying static data without synchronization.
3. If an object represents a view on some other object, the client generally must synchronize on the backing object, so as to prevent its direct modification. For example, the documentation for Collections.synchronizedMap says this: It is imperative that the user manually synchronize on the returned map when iterating over any of its collection views:
Map<K, V> m = Collections.synchronizedMap(new HashMap<K, V>()); ... Set<K> s = m.keySet(); // Needn't be in synchronized block ... synchronized(m) { // Synchronizing on m, not s! for (K key : s) key.f(); }
4. If you write an unconditionally thread-safe class, consider using a private lock object in place of synchronized methods. This protects you against synchronization interference by clients and subclasses and gives you the flexibility to adopt a more sophisticated approach to concurrency control in a later release.
5. Every class should clearly document its thread safety properties with a carefully worded prose description or a thread safety annotation. The synchronized modifier plays no part in this documentation. Conditionally thread-safe classes must document which method invocation sequences require external synchronization, and which lock to acquire when executing these sequences.
相关文章推荐
- 【数据结构与算法】汉诺塔算法——C语言递归实现
- [算法]简单的背包问题递归解法,C语言实现
- 算法思考--------汉诺塔c语言实现-------递归
- 【算法】二叉树的递归遍历C语言实现
- 第三篇:汉诺塔算法——C语言递归实现
- C语言实现二叉树的常用的算法(递归与非递归实现遍历)
- [算法]图算法之骑士遍历问题(象棋中马的遍历问题)分析,C语言实现
- 创建链表的三种算法(C语言实现)——正向、逆向、递归
- C语言经典算法(十)——递归实现汉诺塔
- poj算法-使用C语言在VC++6.0实现poj1753(递归枚举)
- [算法]数据结构算法背包问题解法之递归解法,C语言实现
- 【数据结构与算法】汉诺塔算法——C语言递归实现
- 结点遍历C语言实现二叉树的常用的算法(递归与非递归实现遍历)
- C语言实现快排、归并排序、快排改进算法的递归和非递归算法
- C语言中实现点在多边形内的算法
- 数值计算方法与算法:C语言实现利用Gauss消元法解方程组
- 10个重要的算法C语言实现源代码:拉格朗日,牛顿插值,高斯,龙贝格,牛顿迭代,牛顿-科特斯,雅克比,秦九昭,幂法,高斯塞德尔
- 10个重要的算法C语言实现源代码(其1-拉格朗日)
- 10个重要的算法C语言实现源代码:拉格朗日,牛顿插值,高斯,龙贝格,牛顿迭代,牛顿-科特斯,雅克比,秦九昭,幂法,高斯塞德尔
- 递归调用实现的算法