Disposable resource: lazy allocation
I'm not a fan of the two-step initialization idiom but I've resigned myself to use it if the native object has a lot of configuration options followed by a rather complex and error-prone initialization.
The real issue is that I still have some constructors that throw exceptions after native resources have been allocated, though I'm able to avoid it in most cases.

That's a suspicious set of problems to have; too bad you didn't ask for a review of that code.  Off the top of my head, however, I've generally found that &quot;a lot of configuration options&quot; can usually be managed by a builder, and that trivial constructors seldom throw -- dependency injection pushes the exception risk outside of the constructor, where you can usually manage things more easily.
@Override
public void close() 

If you aren't intending to let people create sub classes that circumvent the state machine, you might make these methods final.
protected abstract T allocate();
protected abstract void release(final T resource);

These methods don't belong here.  The rest of your class is about lifecycle management; these are about resource management.  You've mixed the concern about coordinating the life cycle with your concern for creation.
interface ResourceFactory&lt;T&gt; {
    void T allocate();
    void release(T resource);
}

Then, in your lifecycle management, defer the work to the factory.
@Override
public void close() 
{
    if (this.refState.getAndSet(State.DISPOSED) == State.ALLOCATED)
        this.factory.release(this.resource);
}

10 out of 10 for making the state machine explicit.  I suspect that you should make State.ALLOCATING and State.DISPOSING explicit.  You might also want to look into Stateless4j; trivial state machines often grow in complexity.