Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Since AtomicInteger can be at at least an order of magnitude slower than an int protected by synchronized, why would I ever want to use AtomicInteger?</p> </blockquote> <p>AtomicInteger is much faster.</p> <pre><code>static final Object LOCK1 = new Object(); static final Object LOCK2 = new Object(); static int i1 = 0; static int i2 = 0; static final AtomicInteger ai1 = new AtomicInteger(); static final AtomicInteger ai2 = new AtomicInteger(); public static void main(String... args) throws IOException { for(int i=0;i&lt;5;i++) { testSyncInt(); testAtomicInt(); } } private static void testSyncInt() { long start = System.nanoTime(); int runs = 10000000; for(int i=0;i&lt; runs;i+=2) { synchronized (LOCK1) { i1++; } synchronized (LOCK2) { i2++; } } long time = System.nanoTime() - start; System.out.printf("sync + incr: Each increment took an average of %.1f ns%n", (double) time/runs); } private static void testAtomicInt() { long start = System.nanoTime(); int runs = 10000000; for(int i=0;i&lt; runs;i+=2) { ai1.incrementAndGet(); ai2.incrementAndGet(); } long time = System.nanoTime() - start; System.out.printf("incrementAndGet: Each increment took an average of %.1f ns%n", (double) time/runs); } </code></pre> <p>prints</p> <pre><code>sync + incr: Each increment took an average of 32.4 ns incrementAndGet: Each increment took an average of 20.6 ns sync + incr: Each increment took an average of 31.4 ns incrementAndGet: Each increment took an average of 12.9 ns sync + incr: Each increment took an average of 29.6 ns incrementAndGet: Each increment took an average of 12.9 ns sync + incr: Each increment took an average of 35.1 ns incrementAndGet: Each increment took an average of 16.6 ns sync + incr: Each increment took an average of 29.9 ns incrementAndGet: Each increment took an average of 13.0 ns </code></pre> <hr> <p>Adding some contention as @assylias suggests. It shows that when you are only really using one thread the CPU can optimise the access.</p> <pre><code>static final Object LOCK1 = new Object(); static final Object LOCK2 = new Object(); static int i1 = 0; static int i2 = 0; static final AtomicInteger ai1 = new AtomicInteger(); static final AtomicInteger ai2 = new AtomicInteger(); public static void main(String... args) throws ExecutionException, InterruptedException { for(int i=0;i&lt;5;i++) { testSyncInt(); testAtomicInt(); } } private static void testSyncInt() throws ExecutionException, InterruptedException { long start = System.nanoTime(); final int runs = 1000000; ExecutorService es = Executors.newFixedThreadPool(2); List&lt;Future&lt;Void&gt;&gt; futures = new ArrayList&lt;&gt;(); for(int t=0;t&lt;8;t++) { futures.add(es.submit(new Callable&lt;Void&gt;() { public Void call() throws Exception { for (int i = 0; i &lt; runs; i += 2) { synchronized (LOCK1) { i1++; } synchronized (LOCK2) { i2++; } } return null; } })); } for (Future&lt;Void&gt; future : futures) { future.get(); } es.shutdown(); long time = System.nanoTime() - start; System.out.printf("sync + incr: Each increment took an average of %.1f ns%n", (double) time/runs/2); } private static void testAtomicInt() throws ExecutionException, InterruptedException { long start = System.nanoTime(); final int runs = 1000000; ExecutorService es = Executors.newFixedThreadPool(2); List&lt;Future&lt;Void&gt;&gt; futures = new ArrayList&lt;&gt;(); for(int t=0;t&lt;8;t++) { futures.add(es.submit(new Callable&lt;Void&gt;() { public Void call() throws Exception { for (int i = 0; i &lt; runs; i += 2) { ai1.incrementAndGet(); ai2.incrementAndGet(); } return null; } })); } for (Future&lt;Void&gt; future : futures) { future.get(); } es.shutdown(); long time = System.nanoTime() - start; System.out.printf("incrementAndGet: Each increment took an average of %.1f ns%n", (double) time/runs/2); } </code></pre> <p>prints</p> <pre><code>sync + incr: Each increment took an average of 478.6 ns incrementAndGet: Each increment took an average of 191.5 ns sync + incr: Each increment took an average of 437.5 ns incrementAndGet: Each increment took an average of 169.8 ns sync + incr: Each increment took an average of 408.1 ns incrementAndGet: Each increment took an average of 180.8 ns sync + incr: Each increment took an average of 511.5 ns incrementAndGet: Each increment took an average of 313.4 ns sync + incr: Each increment took an average of 441.6 ns incrementAndGet: Each increment took an average of 219.7 ns </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POWhen is AtomicInteger preferrable over synchronized?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USPeter Lawrey
    1. USPeter Lawrey
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhen is AtomicInteger preferrable over synchronized?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI'm now really confused. That's not what I understood from @Gray's answer here: http://stackoverflow.com/a/11125474/722603 What am I missing?
      singulars
      1. PO
      1. USef2011
    2. COI think he means that `AtomicInteger` is slower than an *unsynchronized* `int`; he's talking about why you shouldn't replace all your `int` members with `AtomicInteger` without justification. But it's not an order of magnitude slower, any more than it's an order of magnitude faster. For the most part these are all small differences we're talking about.
      singulars
      1. PO
      1. USErnest Friedman-Hill
    3. COI remember reading somewhere that locking mechanism also different for Atomic stuff, but couldn't get that reference right now. I may be wrong too.
      singulars
      1. PO
      1. USkosa
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload