aboutsummaryrefslogtreecommitdiff
path: root/website2/templates/features/Synchronized.html
diff options
context:
space:
mode:
Diffstat (limited to 'website2/templates/features/Synchronized.html')
-rw-r--r--website2/templates/features/Synchronized.html34
1 files changed, 0 insertions, 34 deletions
diff --git a/website2/templates/features/Synchronized.html b/website2/templates/features/Synchronized.html
deleted file mode 100644
index 113add0e..00000000
--- a/website2/templates/features/Synchronized.html
+++ /dev/null
@@ -1,34 +0,0 @@
-<#import "_features.html" as f>
-
-<@f.scaffold title="@Synchronized" logline="<code>synchronized</code> done right: Don't expose your locks.">
- <@f.overview>
- <p>
- <code>@Synchronized</code> is a safer variant of the <code>synchronized</code> method modifier. Like <code>synchronized</code>, the annotation can be used on static and instance methods only. It operates similarly to the <code>synchronized</code> keyword, but it locks on different objects. The keyword locks on <code>this</code>, but the annotation locks on a field named <code>$lock</code>, which is private.<br />
- If the field does not exist, it is created for you. If you annotate a <code>static</code> method, the annotation locks on a static field named <code>$LOCK</code> instead.
- </p><p>
- If you want, you can create these locks yourself. The <code>$lock</code> and <code>$LOCK</code> fields will of course not be generated if you already created them yourself. You can also choose to lock on another field, by specifying it as parameter to the <code>@Synchronized</code> annotation. In this usage variant, the fields will not be created automatically, and you must explicitly create them yourself, or an error will be emitted.
- </p><p>
- Locking on <code>this</code> or your own class object can have unfortunate side-effects, as other code not under your control can lock on these objects as well, which can cause race conditions and other nasty threading-related bugs.
- </p>
- </@f.overview>
-
- <@f.snippets name="Synchronized" />
-
- <@f.confKeys>
- <dt>
- <code>lombok.synchronized.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
- </dt><dd>
- Lombok will flag any usage of <code>@Synchronized</code> as a warning or error if configured.
- </dd>
- </@f.confKeys>
-
- <@f.smallPrint>
- <p>
- If <code>$lock</code> and/or <code>$LOCK</code> are auto-generated, the fields are initialized with an empty <code>Object[]</code> array, and not just a <code>new Object()</code> as most snippets showing this pattern in action use. Lombok does this because a new object is <em>NOT</em> serializable, but 0-size array is. Therefore, using <code>@Synchronized</code> will not prevent your object from being serialized.
- </p><p>
- Having at least one <code>@Synchronized</code> method in your class means there will be a lock field, but if you later remove all such methods, there will no longer be a lock field. That means your predetermined <code>serialVersionUID</code> changes. We suggest you <em>always</em> add a <code>serialVersionUID</code> to your classes if you intend to store them long-term via java's serialization mechanism. If you do so, removing all <code>@Synchronized</code> annotations from your method will not break serialization.
- </p><p>
- If you'd like to know why a field is not automatically generated when you choose your own name for the lock object: Because otherwise making a typo in the field name will result in a <em>very</em> hard to find bug!
- </p>
- </@f.smallPrint>
-</@f.scaffold>