Are i++, i-- atomic and thread safe for int i

Question

I want to minimize the sync time multiple threads take to contend for a shared pool, which is implemented as a FIFO. My plan is to:
1. Use a int variable "count" to trace the free obj count. Hence eliminates the need of synchonized methods size() and isEmpty()
2. Increment & decrement count when implemeting push() and pop()
3. Minimize the number of statements in synchonized block as possible within push() and pop(), which in this case, excludes count++ and count-- provided these operations are atomic and thread safe
Have I lost something ?

Answer 1

So, may I make a conclusion.
To minimize contention, I use FIFO instead LIFO or stack and build it from scratch without extending from existing Collection-related class
1 public class FIFO {
2 . . private volatile int count;
3 . . private Object head, tail;
4 . . public Object pop() {
5 . . . .synchonized (tail) {
6 . . . . .if (count >= 3) {
7 . . . . . .Object tail_origin = tail;
8 . . . . . .// Re-organizing the linked list skipped
9 . . . . . .synchonized (this) {
10 . . . . . . count--;
11 . . . . . }
12 . . . . . return tail_origin;
13 . . . . }
14 . . . . else {
15 . . . . . throw new PoolEmptyException();
16 . . . . }
17 . . . }
18 . . }
19 . . public void push(Object o) {
20 . . . synchronized (head) {
21 . . . . . // Re-organizing the linked list skipped
22 . . . . . head = o;
23 . . . . . synchonized (this) {
24 . . . . . . count++;
25 . . . . . }
26 . . . }
27 . . }
28 . . public int sizeOf() {
29 . . . return count;
30 . . }
31 }
1. The reason I choose FIFO is to avoid the contention between push() and pop() -- they are NOT declared as synchonized, instead they only lock head and tail respectively. (Sorry I borrow the name push and pop from stack)
2. pop() only works when count >= 3 to avoid head == tail after pop() and hence a further call to push() block concurrent call to pop() and vice versa (see line 5 and 20)
3. The goal is to minimize the time and scope of contention. In line 9 and 23, I lock the whole pool object only when modify count, which is not atomic.
4. This pool is used for a thread pool supporting many concurrent short-lived HTTP request
Have I missed something ?
Thanks a lot!