I don't know what "You will back to my 2nd solution" means.

This works; I tried it this time:
create sequence fsloke start with 1 maxvalue 1000000 minvalue 1;
select fsloke.nextval from dual;
=> 1
select fsloke.nextval from dual;
=> 2
alter sequence fsloke increment by 20;
select fsloke.nextval from dual;
=> 22
alter sequence fsloke increment by 1;
select fsloke.nextval from dual;
=> 23

In multithreading you will need to mutex this, otherwise you might get:
thread 1: select nextval => 23 Now it thinks it has values 23~122, except along comes the timeslicer and...
thread 2: select nextval => 24 Now it thinks it has the values 24~123 and now the two threads are going to be inserting duplicate key records for 24~122.
You don't need to serialise calls to nextval; that's already threadsafe, it's where you call nextval then assume you have nextval+1~nextval+99 to yourself; you have to prevent other threads getting hold of nextval+1.

Why are you doing this anyway though? Has profiling shown the nextval call to be a problem, or are you just looking at the high number of calls and assuming it will be? Are you using client/server over a network or connecting to a database on the same machine? Premature optimisation is a root of all kinds of evil so make sure you're performing this optimisation for a good reason, and if you haven't got a good reason just use nextval.